Schedules/KDE 3.3 Release Schedule: Difference between revisions
cleaner |
*>Mark Ziegler No edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
KDE 3.3 is the third and quickest feature release in the KDE 3.x series. | KDE 3.3 is the third and quickest feature release in the KDE 3.x series. | ||
The list of planned features can be found in a separate document. | The list of planned features can be found in a [http://developer.kde.org/development-versions/kde-3.3-features.html separate document]. | ||
All dates given here are subject to revision, but we will try our best to stick to them if possible. | All dates given here are subject to revision, but we will try our best to stick to them if possible. | ||
[mailto:[email protected] Stephan Kulow] is acting as release coordinator for the 3.3 releases. | [mailto:[email protected] Stephan Kulow] is acting as release coordinator for the 3.3 releases. | ||
Latest revision as of 13:23, 9 May 2008
KDE 3.3 is the third and quickest 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.3 releases.
KDE 3.3.0
May 23rd, 2004: Alpha 1 prepared
Alpha 1 will be source only, we do not want to take away packager resources from the KDE 3.2.3 happen around that date.
June 1st, 2004: Start of Release
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.
June 22th, 2004: It's getting colder in CVS
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits till 27th. Features should mainly be done by now.
June 26th, 2004: Beta1 prepared
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.
July 14th, 2004: 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 18th.
July 17th, 2004: Beta2 prepared
Beta 2 is tagged and tarballs are made for testing. Tarballs are released to the packagers.
August 4th, 2004: Total Freeze
This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.
August 7st, 2004: RC1 prepared
This release will happen very quickly, so the RC1 will already be labeled 3.3.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_3_BRANCH is created and the final touches are applied in there.
Wednesday August 18th, 2004: Targeted Release date
August 21st starts the "aKademy" and I want to have this done before it, so there is little time left for the packagers and the PR team to get prepared for their trip to Ludwigsburg.
KDE 3.3.1
Saturday October, 2nd, 2004: Tagging KDE_3_3_1_RELEASE
The first translation and bug fix release: Will take its usual week of packaging
KDE 3.3.2
Saturday November, 27th, 2004: Tagging KDE_3_3_2_RELEASE
The second translation and bug fix release: Will take its usual week of packaging and testing
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.3 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 June 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.