Re: GNOME 2.0 planning: A longer range roadmap
- From: Havoc Pennington <hp redhat com>
- To: Maciej Stachowiak <mjs eazel com>
- Cc: gnome-hackers gnome org
- Subject: Re: GNOME 2.0 planning: A longer range roadmap
- Date: 17 Feb 2001 23:03:23 -0500
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 ;-)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]