Schedules/KDE 3.1 Release Schedule: Difference between revisions
(cleaner) |
*>Mark Ziegler No edit summary |
||
Line 1: | Line 1: | ||
KDE 3.1 is the first feature release in the KDE 3.x series. | KDE 3.1 is the first 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.1-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. | ||
Latest revision as of 13:24, 9 May 2008
KDE 3.1 is the first 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.
Dirk Mueller is acting as release coordinator for the 3.1 releases.
KDE 3.1.0
Monday July 1, 2002: Preparing Alpha1 and feature plan freeze
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.1 Alpha 1 is tagged and tarballs are made for testing.
Monday July 8, 2002: Alpha1 release
Alpha 1 is announced.
Monday August 5, 2002: Preparing Beta1
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits. Tarballs are released to the packagers.
Monday August 19, 2002: Announcement Beta1
Beta 1 is announced.
Monday September 16, 2002: Preparing Beta2
3.1 Beta 2 is tagged and tarballs are made for testing. Announcement a week later.
Monday September 23, 2002: Announcement Beta2
3.1 Beta2 is released to the public.
Monday September 30, 2002: i18n string freeze
The i18n strings are frozen. The HEAD branch is frozen for release. Any non-trivial patches to CVS have to be approved by at least one other related developer.
Monday October 28, 2002: Preparing RC 1
3.1 RC1 tarballs are made and uploaded for testing.
Monday November 4, 2002: Preparing RC 2
3.1 RC2 tarballs are made and uploaded for testing.
Monday November 11, 2002: Preparing RC 3
3.1 RC3 tarballs are made and uploaded for testing.
Sunday November 17th, 2002: Last day for i18n changes
Last day for i18n commits which will go into 3.1 final.
Monday November 18th, 2002: Preparing RC 4
3.1 RC4 is tagged and being made available to the packagers.
Friday December 6th, 2002: Preparing RC 5
3.1 RC5 tarballs are generated and uploaded for testing.
Friday January 3rd, 2003: Preparing RC 6
3.1 RC6 tarballs are generated and uploaded for testing.
Tuesday January 28th, 2003: KDE 3.1 Release
KDE 3.1 was announced
KDE 3.1.1
Friday March 7th, 2003: Preparing KDE 3.1.1
KDE 3.1.1 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
KDE 3.1.2
Monday May 5th, 2003: Preparing KDE 3.1.2
KDE 3.1.2 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
KDE 3.1.3
Monday July 14th, 2003: Preparing KDE 3.1.3
KDE 3.1.3 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.
KDE 3.1.4
Monday September 8th, 2003: Preparing KDE 3.1.4
KDE 3.1.4 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.1 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 July 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.