[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    RfC: KDE 3.0 release plan
From:       Dirk Mueller <mueller () kde ! org>
Date:       2001-09-07 19:52:41
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]