Schedules/KDE 3.0 Release Schedule: Difference between revisions

From KDE Community Wiki
(clean)
*>Mark Ziegler
No edit summary
 
Line 1: Line 1:
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 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.
The list of planned features can be found in a [http://developer.kde.org/development-versions/kde-3.0-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:26, 9 May 2008

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.0

Monday September 24th, 2001: Preparing Alpha1

The HEAD branch should be made ready to compile and work flawlessly with the current Qt 3.x beta / release version.

Friday October 5th, 2001: Release Alpha1

The HEAD branch is tagged as developer-release / alpha named KDE_2_9_RELEASE and tarballs are made.

Friday November 2nd, 2001: Feature 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.

Monday December 12th, 2001: Preparing Beta1

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 19th, 2001: Beta1 release

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 28th, 2002: Preparing Beta2

3.0 Beta 2 is tagged and tarballs are made for testing. The HEAD branch is frozen for release. i18n is completeley frozen for string changes by developers. Any nontrivial patches to CVS has to be approved by at least another developer. Announcement a week later.

Wednesday February 13th, 2002: Announcement Beta2

3.0 Beta2 is released to the public.

Monday March 4th, 2002: Preparing RC 1

3.0 RC1 tarballs are made and uploaded for testing.

Friday March 8th, 2002: Preparing RC 2

3.0 RC2 tarballs are made and uploaded for testing.

Monday March 18th, 2002: Preparing RC 3

3.0 RC3 tarballs are made and uploaded, which incorporate the CVS changes since RC2 tarballs. Remaining showstoppers are identified. The tarballs are made available to the packagers and put up on ftp. Binary packages will be publically announced together with the source tarballs as soon as they become available.

Thursday March 21th, 2002: Decision about 3.0 final

Manually selected changes since the RC3 tarballs are integrated into the proposed final tarballs, labeled RC4. A check of the showstopper list will decide if these tarballs are final. In this case, they're made available to the packagers and roughly a week later announced to the public. If not, the schedule is delayed by another week.

Monday March 25th, 2002: tarballs made available to the packagers

The final tarballs are made available to the packagers. The remaining week is used to prepare the changelog and the announcement.

Wednesday April 3rd, 2002: KDE 3.0 announcement

The final tarballs are made available on ftp.kde.org and the release is announced.

KDE 3.0.

Wednesday May 8th, 2002: 3.0.1 tarballs are made available to the packagers

the KDE_3_0_BRANCH is tagged as KDE_3_0_1_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

Wednesday May 22th, 2002: 3.0.1 is announced

The tarballs and the binary packages are announced to the public after some delays.

KDE 3.0.2

Monday June 24th, 2002: 3.0.2 tarballs are made available to the packagers

The KDE_3_0_BRANCH is tagged as KDE_3_0_2_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

KDE 3.0.3

Wed August 7th, 2002: 3.0.3 tarballs are made available to the packagers

The KDE_3_0_BRANCH is tagged as KDE_3_0_3_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

KDE 3.0.4

Wed September 25th, 2002: 3.0.4 tarballs are made available to the packagers

The KDE_3_0_BRANCH is tagged as KDE_3_0_4_RELEASE and tarballs are made for 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.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 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.