Schedules/KDE 3.4 Release Schedule

    From KDE TechBase
    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 3.4 is the fourth (and most likely last) 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.4 releases.

    KDE 3.4.0

    December 6th, 2004: Alpha 1 prepared

    Alpha 1 will be source only - without translations.

    December 18th, 2004: HEAD is feature frozen

    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. The feature list closes for unreviewed changes that day.

    January 3rd, 2005: KDE_3_4_BETA1 tag

    The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits till 8th. Features should mainly be done by now.

    January 7th, 2005: Beta1 is prepared

    Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.

    February 2nd, 2005: 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 6th The only exception to the message freeze in the first week is the typo and style guide fixing of last minute feature commits.

    February 4th, 2005: KDE_3_4_BETA_2

    Beta 2 is tagged and tarballs are made for testing. Tarballs are released to the packagers.

    February 22nd, 2005: Total release freeze

    This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.

    February 26th, 2005: Release Candidate 1

    This release will happen very quickly, so the RC1 will already be labeled 3.4.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_4_BRANCH is created and the final touches are applied in there.

    Wednesday March 16th, 2005: Targeted Release date

    KDE 3.4.1

    Monday May 23rd, 2005: Creating tags/KDE/3.4.1/

    The first translation and bug fix release. Please add your changes to
    trunk/www/sites/www/announcements/changelogs/changelog3_4to3_4_1.php.

    Tuesday May 31st, 2005: Targeted 3.4.1 Release date

    KDE 3.4.2

    Wednesday July 20th, 2005: Creating tags/KDE/3.4.2/

    The second translation and bug fix release. Please add your changes to
    trunk/www/sites/www/announcements/changelogs/changelog3_4_1to3_4_2.php.

    Wednesday July 27th, 2005: Targeted 3.4.2 Release date

    KDE 3.4.3

    Wednesday October 5th, 2005: Creating tags/KDE/3.4.3/

    The third translation and bug fix release. Please add your changes to
    trunk/www/sites/www/announcements/changelogs/changelog3_4_2to3_4_3.php.

    Wednesday October 12th, 2005: Targeted 3.4.3 Release date

    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.4 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 December 18th 2004. 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.