The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
KDE is becoming a very big project. To be able to make a release of KDE a lot
of cooperation between all developers is needed. To make clear to everyone
what is required to make a successful release a schedule is made.
This schedule should be seen as a guideline and not as a strict scheme.
Hopefully this release schedule can contribute to the fun and quality of KDE.
KDE Release Schedules
Two schedules are presented here. A major release takes approx. 5 (!!) months
from the first announcement to the final release. A minor release takes approx.
2 months. Schedules for major
releases and for minor releases.
The dates mentioned serve as an indication only. They reflect the expected
duration of a certain phase. If required by the circumstances, the release
dude is free to increase the time between steps. In this case, the release
dude will inform all KDE mailinglists about the adjustments in the release
schedule as well as the reason for the adjustments.
Example: "The KFM authors want to add javascript support in KHTML before
the freeze and will need at least 3 more weeks for this. Therefore the
freeze of the KDE libraries has been delayed till at least 1 Aug 2001."
If a developer would like to see the release delayed he/she should inform
the release dude about this as soon as possible. The release dude will
decide whether the release will be delayed or not. (Possibly after
consulting others)
Example: "Can we wait with the release till Qt3.54 has been released?
I want to use the xyz widget the Trolls have added in my abc application."
Schedule (Major Release)
Step 1
|
Start of the Release
|
Date: wk 0
|
- A release dude is appointed who will implement this schedule.
- It is decided which libraries will be released.
- A Release Announcement is made which is also published on the appropriate mailing lists.
|
Evaluation |
|
Date: wk 3
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 2
|
Library Freeze
|
Date: wk 4
|
|
Evaluation |
|
Date: wk 7
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 3
|
Application Freeze
|
Date: wk 8
|
|
Evaluation |
|
Date: wk 11
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 4
|
Ready for translation
|
Date: wk 12
|
|
Evaluation |
|
Date: wk 15
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 5
|
Final Release
|
Date: wk 16
|
- Debugging messages are turned off by default.
- The code is checked for left over debug output.
- A source-only gamma-release is made without translations.
- The SVN trunk is copied to tags/
- All parts are free to modify again.
- A Release Announcement is made which is also published on the appropriate mailing lists.
- Translations can finalize and packagers can start to prepare themselves.
- The "What's changed?" should be finished by now!
- A "Press Release" should be written.
|
Evaluation |
|
Date: wk 18
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made if the next step is delayed.
|
Step 6
|
Tagging of the Release
|
Date: wk 18
|
This should happen during a weekend.
- All translations should be finished and have been put into SVN.
- The gamma-release is now the final-release. It should not have changed much since the previous step. The according tags/ copy is created in SVN.
- The tarballs of the release are made available to the packagers (and the packagers only).
- The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
- The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated (on both ftp and www).
|
Evaluation |
|
Date: wk 18
|
- It is evaluated whether the next step needs to be delaye
|
Step 7
|
Final Release
|
Date: wk 19
|
This should happen on a Monday, one week after Step 6.
- kde-pr sends out the press release.
- kde-pr informs all KDE lists and updates the web-pages.
- Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
- The binary and source packages are made world-wide available on the ftp-server.
- The release is complete.
- PARTY!!!!
|
Schedule (Minor Release)
Step 1
|
Start of the Release
|
Date: wk 0
|
- A release dude is appointed who will implement this schedule.
- It is decided which applications and libraries will be released.
- A Release Announcement is made which is also published on the appropriate mailing lists.
|
Evaluation |
|
Date: wk 3
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 2
|
Application Freeze
|
Date: wk 4
|
|
Evaluation |
|
Date: wk 6
|
- It is evaluated whether the next step needs to be delayed.
A Release Announcement is made with the result of the evaluation.
|
Step 3
|
Ready for translation
|
Date: wk 6
|
- Core libraries are deep-frozen for the SVN branch to release.
- Core applications are deep-frozen for the SVN branch to release.
- Debugging messages are turned off by default.
- The code is checked for left over debug output.
- The SVN branch is created
- A source-only gamma-release is made which can be translated. Packagers can prepare themselves using the gamma-release.
- A Release Announcement is made.
- A "What's changed?" should be written.
- A "Press Release" should be written.
|
Step 4
|
Final Release
|
Date: wk 8
|
This should happen during a weekend.
- All translations should be finished and have been put into SVN.
- The gamma-release is now the final-release. It should not have changed since the previous step. The release tags/ path is created in SVN.
- The tarballs of the release are made available to the packagers. (And the packagers only).
- The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
- The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated. (on both ftp and www)
|
Step 5
|
Final Release
|
Date: wk 9
|
This should happen on a Monday, one week after Step 4.
- kde-pr sends out the press release.
- kde-pr informs all KDE lists and updates the web-pages.
- Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
- The binary and source packages are made world-wide available on the ftp-server.
- The release is complete.
- PARTY!!!!
|
Terms
Major Release
- A major KDE release has two version numbers, eg KDE 1.1. Only a major KDE release will incorporate new features.
Minor Release
- For minor releases a shortened release schedule will be used. A minor KDE release has three version numbers, eg. KDE 1.1.1. A minor KDE release concentrates on fixing bugs, minor glitches and small usability issues. A minor release is based on a SVN branch of a previous release and does not affect the trunk of SVN.
Release Announcement
- A Release Announcement is an announcement related to a release and coupled to a certain step or evaluation. A Release Announcement is sent to ALL KDE mailinglists. It contains a pointer to this document ("KDE Release Schedule") The anouncement includes the current state of the release and describes which parts of SVN are free to modify, feature-frozen or deep-frozen. Each announcement includes in a "What Next?" section what the next step of the release will be and how many weeks/days are left till this step is reached. Release Announcements are repeated weekly, if the next step is within the next week, the announcement is repeated daily.
Free to modify
- No special restrictions with regard to changes.
Feature frozen
- No new features, texts may be changed, focus should be on bug fixing.
Deep frozen
- No new features, no changes of texts, only severe bugs may be fixed after two developers have seen a patch and agreed on it.
Core libraries
- All the libraries which will be released.
Core applications
- All the applications which will be released.