GNOME 2.0 planning: A longer range roadmap

[Maciej Stachowiak <mjs eazel com>]

Hey guys,

As predicted, everyone has their own favorite feature for gnome 2.0,
and no one wants to hear about their own feature being cut. I have a
proposal for dealing with this.

Instead of just planning GNOME 2.0 now, let's think about a couple of
releases after 2.0. The Foundation board proposed having a new major
(potentially compat breaking) release once every 9-12 months. I have
personally proposed doing point releases at least every three months.

If we look a couple of releases ahead, we don't have the choice only
between "will be done for GNOME 2" and "will never get done". We can
say "will be done for this other release".

So, making a couple of assumptions, I can imagine a rough schedule of:


27-03-2001 - GNOME 1.4

??-06-2001 - GNOME 1.4.1

??-09-2001 - GNOME 1.4.2 (or maybe 1.4.5 or 1.6 if we add evolution to
                          the core release here)

??-12-2001 - GNOME 2.0

??-03-2002 - GNOME 2.0.1

??-06-2002 - GNOME 2.2

??-09-2002 - GNOME 2.2.1

??-12-2002 - GNOME 3.0

??-??-???? - post gnome 3.0

The rules for these could be:

1.4.1, 2.0.1, 2.2.1:  bug fix only; minor additions as needed.

1.4.2/1.4.5/1.6, 2.2: full source and binary compat, but platform
                      additions may happen.


2.0, 3.0:             Backwards source and bin compat may be broken.


So when you have a particular feature or library change in mind,
instead of discussing "in for gnome 2" vs. "out for gnome 2", let's
discuss "where on the road map do we want this done?"


Another thing that I think will help is setting a HARD API/feature
freeze for all libraries for GNOME 2.0. Say for instance any changes
that are not done by the end of July or August or so are not on the
train for 2.0, unless they are major release blocking issues like
porting to Gtk+ 2.0.


I think plotting more of the roadmap, and picking a freeze date for
library features now (when we set it depends on how much we want to
prioritize platform vs. user environment changes), will lead to a
framework for a more constructive conversation.


I would love to post more on my specific thoughts about 2.0 but I have
to kinda keep my head down with the 1.4 release for now.

 - Maciej