Dirk Mueller: KDE 3.0 release plan

Subject: RFC: KDE 3.0 release plan
Date: Fri, 7 Sep 2001 21:52:41 +0200
From: Dirk Mueller 

Hi,

I've set up a release plan on

http://developer.kde.org/development-versions/kde-3.0-release-plan.html

It will become active in a week if there are no disagreements.

For convenience I append the contents:

                        Status: Request for Comments

                            KDE 3.0 Release Plan

   The following is the outline for our KDE 3.0 release schedule.
   The major change in KDE 3.0 will be the switch to Qt 3, as well as
 new features and bugfixes that involve bigger changes or require
 breaking binary compatibility. The plan is to make KDE ready for a
 long period of binary compatible releases.

   The list of planned features can be found in a separate document.

   All dates given here are subject to revision, but we will try our
 best to stick to them if possible.

   Dirk Mueller is acting as release coordinator for the 3.0
   releases .

KDE 3.0

Monday September 24

   The HEAD branch should be made ready to compile and work
 flawlessly with the current Qt 3.x beta / release version.

Monday October 1

   The HEAD branch is tagged as developer-release / alpha named
   KDE_2_9_RELEASE and tarballs are made.

Friday November 2

   The HEAD branch is frozen for feature commits that are not listed
 in the planned-feature document. Only bugfixes and the listed
 feature-commits are to be committed. Still, binary compatibility is
 not required, i18n string changes are allowed.

Monday November 26

   KDE 3.0 Beta 1 is tagged and tarballs are made for testing. The
 HEAD branch is frozen except for urgent bug- and compile fixes.

   The rest of the week is spent testing the tarballs, packaging and
   writing the announcement and changelog.

Monday December 3

   Beta 1 is announced. The HEAD branch is frozen except for bugfixes
 and for the eventually outstanding feature commits listed in the
 planned-feature document. i18n string changes are to be kept at a
 minimum to allow translation teams that have to start from scratch
 to get a certain amount of work done.

Monday January 7

   3.0 RC 1 is tagged and tarballs are made for testing. The HEAD
 branch is frozen for release. i18n is completeley frozen. Any
 nontrivial patches to CVS have to be approved. Announcement a week
 later.

Monday February 11

   In case RC 1 turns out well 3.0-final is tagged and being tested
 for a week. A week later releasing to packagers.

Monday February 25

   announcement 3.0-final (or RC 2 in case it is necessary).

Frequently Asked Questions

What's the deal with that feature-plan?

   In the past, there were a lot of complaints about a rather long
   "freeze period", so this is an attempt to address this issue.
   Basically the idea is that you add an entry about what feature you
   want to finish in the 3.0 timeframe and mark it as done when you
   completed it. This helps me to get an overview about the
 outstanding changes and in return allows you to work on the missing
 parts even in the "freeze period".

   The feature-plan is open for commits till November, 2nd. Later
   additions require reviewal first. I will try to respect
 outstanding entries in the release schedule.

   Please understand that although this gives you greater freedom
 over CVS, it also requires more discipline in making sure that your
 additions don't have unwanted side effects.


Thanks,


Dirk