Schedules/KDE 3.5 Release Schedule: Difference between revisions
m (KDE 3.5 Release Schedule moved to Schedules/KDE 3.5 Release Schedule: subpagify) |
(update to be in line with current release plans) |
||
| Line 65: | Line 65: | ||
==October 10th, 2006: Expected release date of KDE 3.5.5== | ==October 10th, 2006: Expected release date of KDE 3.5.5== | ||
==October 12th, 2006: Partial lift of message and documentation freeze== | |||
For the GUI strings (also known as messages), you can fix typos and make small changes to them. You can also add new error messages to improve error feedback to users. (Adding other kinds of messages are not allowed. In case of questions or doubts, please ask the [email protected] mailing list.) | |||
For the documentation, the changes should also be rather small, except when fixing inaccurate or outdated documentation. You can also port documentation that has been prepared in the trunk/KDE modules. (If you change any documentation for the KDE 3.5 branch, please be sure that the change is also in the corresponding module of trunk/KDE. However you can do a little later, in case that you would not have much time during the lift period.) | |||
==December 16th, 2006: Message and documentation freeze== | |||
After this date 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). | |||
==January 15th, 2007: Tagging KDE 3.5.6== | |||
==January 23rd, 2007: Expected release date of KDE 3.5.6== | |||
==Frequently Asked Questions== | ==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.5 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".<br />The feature-plan is open for commits till August 1st 2005. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule.<br />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. | ;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.5 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".<br />The feature-plan is open for commits till August 1st 2005. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule.<br />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. | ||
Revision as of 21:31, 6 December 2006
KDE 3.5 is the fifth (and this time really last) feature release in the KDE 3.x series. 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.5 releases.
August 1st, 2005: Officially close of feature list
The list of features for KDE 3.5 should already be settled by then, but after that date are only KDE 4 features. At this date, /branches/KDE/3.5 is frozen for feature commits that are not listed in the feature plan.
August 5th, 2005: Alpha 1 prepared
Alpha 1 will be source only - without translations.
August 25th, 2005: branches/KDE/3.5 is feature frozen
The 3.5 branch is frozen for feature commits. Only bugfixes are to be committed. Still, binary compatibility is not required, i18n string changes are allowed.
September 5th, 2005: Message Freeze
After this date 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).
September 10th, 2005: tags/KDE/3.5-beta1 created
The 3.5 branch is tagged as Beta 1 and is frozen for nonurgent commits till 14th.
September 13th, 2005: Beta1 is prepared
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.
October 9th, 2005: tags/KDE/3.5-beta2 created
The 3.5 branch is tagged as Beta 2 and is frozen for nonurgent commits till 12th.
October 12th, 2005: Beta2 is prepared
Beta 2 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.
November 7th, 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.
November 9th, 2005: Release Candidate 1
Targetted date for first release candidate and then wait for show stoppers to appear.
November 29th, 2005: Targetted Release Date
January 20th, 2006: Tagging KDE 3.5.1
February 26th, 2006: Message and documentation freeze
March 17th, 2006: Tagging KDE 3.5.2
May 23th, 2006: Tagging KDE 3.5.3
July 10th, 2006: Message and documentation freeze
July 24th, 2006: Tagging KDE 3.5.4
August 8th, 2006: Partial lift of message and documentation freeze
For the GUI strings (also known as messages), you can fix typos and make small changes to them. You can also add new error messages to improve error feedback to users. (Adding other kinds of messages are not allowed. In case of questions or doubts, please ask the [email protected] mailing list.) For the documentation, the changes should also be rather small, except when fixing inaccurate or outdated documentation. You can also port documentation that has been prepared in the trunk/KDE modules. (If you change any documentation for the KDE 3.5 branch, please be sure that the change is also in the corresponding module of trunk/KDE. However you can do a little later, in case that you would not have much time during the lift period.)
September 18th, 2006: Message and documentation freeze
October 1st-3rd, 2006: Tagging KDE 3.5.5
The actual date depends on how well the Release Coordinator returns from Dublin.
October 10th, 2006: Expected release date of KDE 3.5.5
October 12th, 2006: Partial lift of message and documentation freeze
For the GUI strings (also known as messages), you can fix typos and make small changes to them. You can also add new error messages to improve error feedback to users. (Adding other kinds of messages are not allowed. In case of questions or doubts, please ask the [email protected] mailing list.)
For the documentation, the changes should also be rather small, except when fixing inaccurate or outdated documentation. You can also port documentation that has been prepared in the trunk/KDE modules. (If you change any documentation for the KDE 3.5 branch, please be sure that the change is also in the corresponding module of trunk/KDE. However you can do a little later, in case that you would not have much time during the lift period.)
December 16th, 2006: Message and documentation freeze
After this date 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).
January 15th, 2007: Tagging KDE 3.5.6
January 23rd, 2007: Expected release date of KDE 3.5.6
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.5 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 August 1st 2005. 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.