Re: GNOME 2.0 planning: A longer range roadmap

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs eazel com> writes: 
> 
> ??-12-2001 - GNOME 2.0
> 
...
> 
> ??-12-2002 - GNOME 3.0
> 

I think I started this discussion out wrong, and we made it too
complicated. What about this plan:

 - each release forever in the future is focused on user environment
   features, as befits a desktop project

 - for each compat-breaking release, we consider adding stuff to
   libgnome, libgnomeui [1] that has been stabilized in a separate
   module, and do cleanups for existing libgnome, libgnomeui features.
   New features should never be "born" in libgnome or libgnomeui or
   made a requirement for releasing those libs. The feature adds and
   source-compat-breaking cleanups have to go in by a freeze date well
   before the final release.

 - new devel platform modules can be added at any point release, 
   as long as the maintainer considers the module ready to support
   and is willing to freeze source/binary until the next
   compat-breaking release.

 - libraries do not have to be devel platform modules, they can be
   "stuff the panel and Nautilus happen to share" or
   "unreleased/experimental."  In general we should require #define
   I_AM_THE_PANEL_OR_NAUTILUS type of stuff for these so people don't
   use them accidentally.

Thus, we only have to worry about stabilizing the applications, and
are never in a rush to stabilize supported APIs. The
experimental/nonpublic libraries are considered parts of applications.

Basically we don't really ever want to stop development on devel
platform or on user features, but the 1.5 year release cycle is really
lame and detrimental to the project. So we make the project release
cycle depend only on user features, and have devel platform work go on
in parallel, much as GtkHTML, GTK+, Bonobo, etc. have been doing
recently while gnome-libs remains frozen.

That's a long-term viable solution because it makes this whole
argument simply go away permanently, and lets everyone do the work
they want to do on a continuous basis, and lets all types of work get
released regularly.

It's also what we've ended up doing in practice for 1.2 and 1.4
anyhow, pretty much.

Havoc


[1] I'm not going to say gnome-libs, which is the stupid bundle of
stuff that should be unbundled ;-)

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers