Timescale
=========
2.0 took 36 months: 1999-02-24 => 2002-03-08
2.2 took 9 months: 2002-03-08 => 2002-12-20
2.4 took 15 months: 2002-12-20 => 2004-03-16
Advantages of short releases:
- Easier to keep on schedule
- Easier to make minor API improvements and get them out quickly
- Easier to make performance and UI improvements and get them
out quickly
- Less pressure to backport stuff to the stable branch
- "Baby steps" for development gives less risk
Disadvantage of short releases:
- We have to work really hard to make sure new APIs get enough
review and testing.
- We seem to have trouble doing them :-)
My feeling is that 9-12 months is the right timescale for a
GTK+ release. What I'd propose is that we shoot for 2.8 in
December; I think that with all the API additions in 2.6 we
need a release on the shorter end of things to consolidate.
As a straw-man schedule:
March 16 2004 2.4.0 released
June 15 2004 Cut off for major features existing in prototype form
August 15 2004 Major features are in tree, 2.5.0 release (releases
every other week until 2.6.0)
October 15 2004 API slush-freeze
December 15 2004 2.6.0 released
Possible features
=================
http://www.gtk.org/plan/2.6/ has a pretty complete list of
things that have been discussed. Clearly, doing all of this
is not compatible with a short timescale.
Possible "major themes" for the release
- Win32 support; integration of Win32 native theme, IME IMModule
- Replacing libgnome/libgnomeui - Wizard, App window, command
line option parsing, session management
- Better language binding support - full introspection, etc.
Procedural stuff
================
* Regular team IRC meetings; probably biweekly, public logs and summary
* Releases makers chosen by volunteer at proceeding team meeting
* Roughly monthly 2.4.x minor releases; "theme per release"?
Open procedural questions
=========================
* How the heck do we get ahead of bugzilla?
Attachment:
signature.asc
Description: This is a digitally signed message part