Schedules/KDE 3.4 Release Schedule
KDE 3.4 is the fourth (and most likely last) 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.4 releases.
- 1 December 6th, 2004: Alpha 1 prepared
- 2 December 18th, 2004: HEAD is feature frozen
- 3 January 3rd, 2005: KDE_3_4_BETA1 tag
- 4 January 7th, 2005: Beta1 is prepared
- 5 February 2nd, 2005: Feature Freeze, Message Freeze
- 6 February 4th, 2005: KDE_3_4_BETA_2
- 7 February 22nd, 2005: Total release freeze
- 8 February 26th, 2005: Release Candidate 1
- 9 Wednesday March 16th, 2005: Targeted Release date
- 10 Monday May 23rd, 2005: Creating tags/KDE/3.4.1/
- 11 Tuesday May 31st, 2005: Targeted 3.4.1 Release date
- 12 Wednesday July 20th, 2005: Creating tags/KDE/3.4.2/
- 13 Wednesday July 27th, 2005: Targeted 3.4.2 Release date
- 14 Wednesday October 5th, 2005: Creating tags/KDE/3.4.3/
- 15 Wednesday October 12th, 2005: Targeted 3.4.3 Release date
- 16 Frequently Asked Questions
December 6th, 2004: Alpha 1 prepared
Alpha 1 will be source only - without translations.
December 18th, 2004: HEAD is feature frozen
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. The feature list closes for unreviewed changes that day.
January 3rd, 2005: KDE_3_4_BETA1 tag
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits till 8th. Features should mainly be done by now.
January 7th, 2005: Beta1 is prepared
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.
February 2nd, 2005: Feature Freeze, Message Freeze
After this date only bug fixes are allowed and the same message freeze applies as for released versions (i.e. only previously untranslated strings or clear errors in strings can be fixed - no new strings) The HEAD branch is frozen for nonurgent commits till 6th The only exception to the message freeze in the first week is the typo and style guide fixing of last minute feature commits.
February 4th, 2005: KDE_3_4_BETA_2
Beta 2 is tagged and tarballs are made for testing. Tarballs are released to the packagers.
February 22nd, 2005: Total release freeze
This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.
February 26th, 2005: Release Candidate 1
This release will happen very quickly, so the RC1 will already be labeled 3.4.0. So if there's nothing wrong with it, we will change the file names and are done (I can have dreams too, no?). With this release a KDE_3_4_BRANCH is created and the final touches are applied in there.
Wednesday March 16th, 2005: Targeted Release date
The first translation and bug fix release. Please add your changes to
Tuesday May 31st, 2005: Targeted 3.4.1 Release date
The second translation and bug fix release. Please add your changes to
Wednesday July 27th, 2005: Targeted 3.4.2 Release date
The third translation and bug fix release. Please add your changes to
Wednesday October 12th, 2005: Targeted 3.4.3 Release date
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.4 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 December 18th 2004. 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.