KDE 3.2 is the second feature release in the KDE 3.x series. 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.
Stephan Kulow is acting as release coordinator for the 3.2 releases.
- 1 KDE 3.2.0
- 1.1 August 22nd - 31st, 2003: KDE conference
- 1.2 September 1st, 2003: Start of Release Cycle
- 1.3 September 8th, 2003: Alpha1 release
- 1.4 September 21st, 2003: Alpha2 prepared
- 1.5 Sunday October 26th, 2003: Preparing Beta1
- 1.6 Wednesday November 26th, 2003: CVS is frozen for a moment
- 1.7 Sunday November 30th, 2003: Preparing Beta2
- 1.8 Sunday January 11th, 2004: CVS is frozen for release
- 1.9 Sunday January 18th, 2004: Release Candidate 1 is prepared
- 1.10 Tuesday February 3rd, 2004: Release Party
- 2 KDE 3.2.1
- 3 KDE 3.2.2
- 4 KDE 3.2.3
- 5 Frequently Asked Questions
August 22nd - 31st, 2003: KDE conference
Many KDE developers will meet in Nove Hrady, Czech Republic to discuss what final touches are missing for KDE 3.2 and update the feature plan.
September 1st, 2003: Start of Release Cycle
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. KDE 3.2 Alpha 1 is tagged and tarballs are made for testing.
September 8th, 2003: Alpha1 release
Alpha 1 ("Brokenboring") is announced. The incoming bugs will be reviewed for their severity.
September 21st, 2003: Alpha2 prepared
Alpha 2 is tagged and tarballs are made for testing.
Sunday October 26th, 2003: Preparing Beta1
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits. Tarballs are released to the packagers.
Wednesday November 26th, 2003: CVS is frozen for a moment
The HEAD branch is only open for show stopper bug fixes and very secure changes.
Sunday November 30th, 2003: Preparing Beta2
The HEAD branch is tagged as Beta 2 and is released to the packagers. When the binaries are ready (to be expected 4th of December), the CVS opens again for the way it was after Beta1. As most are to be expected to be on vacation towards the end of the year, commiters are asked to be very conservative with their changes and ask for second views on the lists.
Sunday January 11th, 2004: CVS is frozen for release
The HEAD branch is only open for show stopper bug fixes. A last time merge for the translations is done and as that has happened, the last remaining docs patches are put into CVS.
Sunday January 18th, 2004: Release Candidate 1 is prepared
Release Candidate 1 is prepared and tagged as KDE_3_2_0_RELEASE and a KDE_3_2_BRANCH is created. New Release Candidates will be released as show stopper bugs appear (and are fixed). If everything goes fine...
Tuesday February 3rd, 2004: Release Party
KDE 3.2 will be made available for download, PR materials will be uploaded to the website and an official announcement will follow.
Sunday February 29th, 2004: Preparing KDE 3.2.1
KDE 3.2.1 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
Sunday April 4th, 2004: Preparing KDE 3.2.2
KDE 3.2.2 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
Sunday May 30th, 2004: Preparing KDE 3.2.3
KDE 3.2.3 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
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.2 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 September 1st. Later additions require review first. I will try to respect outstanding entries in the release schedule.
Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.