Schedules/Release Schedules Guide

From KDE TechBase
< Schedules
Revision as of 16:46, 29 December 2006 by Dhaumann (talk | contribs) (initial port of http://developer.kde.org/development-versions/release.html)

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.
Retrieved from "https://techbase.kde.org/index.php?title=Schedules/Release_Schedules_Guide&oldid=6080"