KDE Core/ReleasesProposal: Difference between revisions
< KDE Core
m Fixes |
|||
| (13 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
= Releases from KDE SC 4.12 and beyond = | = Releases from KDE SC 4.12 and beyond = | ||
=== Motivation === | === Motivation === | ||
The main motivation for this change is to reduce the amount of time between releases, making us able to deliver new features faster to our users while keeping if not improving the current quality. | The main motivation for this change is to reduce the amount of time between releases and make them simpler, making us able to deliver new features faster to our users while keeping if not improving the current quality. | ||
=== Proposed changes === | === Proposed changes === | ||
| Line 8: | Line 8: | ||
*Two month for merging features | *Two month for merging features | ||
*One month to prepare the release | *One month to prepare the release | ||
=== Tentative schedule for 4.12 === | === Tentative schedule for 4.12 === | ||
| Line 30: | Line 17: | ||
** Dependencies are frozen | ** Dependencies are frozen | ||
** Artwork/Bindings frozen | ** Artwork/Bindings frozen | ||
** API | ** API frozen | ||
* Release candidate: October 30, 2013 (2 weeks after Beta 1) | * Release candidate: October 30, 2013 (2 weeks after Beta 1) | ||
* Release 4.12 final: November 15, 2013 (One month after 4.12 branching) | * Release 4.12 final: November 15, 2013 (One month after 4.12 branching) | ||
* Release 4.12.1: December 15, 2013 | * Release 4.12.1: December 15, 2013 | ||
* Release 4.12.2: January 15, 2014 | * Release 4.12.2: January 15, 2014 | ||
=== Tentative schedule for 4.13 === | === Tentative schedule for 4.13 === | ||
| Line 45: | Line 31: | ||
* Release 4.13.1: March 15, 2014 | * Release 4.13.1: March 15, 2014 | ||
* Release 4.13.2: April 15, 2014 | * Release 4.13.2: April 15, 2014 | ||
=== In a picture === | === In a picture === | ||
[[File:Drawing.png|KDE Releases]] | [[File:Drawing.png|KDE Releases]] | ||
=== Freezes === | |||
All the freezes will be effective the day of the branching, this include: | |||
* String freeze | |||
* Dependency freeze | |||
* Feature freeze | |||
* ... | |||
=== Maintainers === | |||
Since we will be decreasing the amount of time for testing, it is specially important that only features that are reviewed and stable are merged into master. Saying it in another way master should be always in a state where we can make a release from it. | |||
If you had plans for 4.12 already, '''keep them'''! Even though 4.12 would be released 3 months sooner than it was planned, 4.13 will be released around the time (Mid Jan/Feb 2014), so no need to re-adjusts already made plans. | |||
Said it in another way, instead of having 1 release of 6 months we are having 2 of 3. | |||
=== Developers === | |||
Not much changes besides the fact that releases become way '''simpler''' since we'll have 1 freeze day where '''everything''' will be frozen, instead of having different days spread across the release cycle. | |||
Additionally missing a freeze becomes less important since releases will be done more often. | |||
=== Distributions === | |||
====Benefits==== | |||
* Since we have shorter release cycles it is more probable that distros will be able to pick up more recent version of KDE SC | |||
* Master will be always in a releasable state | |||
* Cycles with less changes, will have less bugs | |||
*Since cycles will have less changes, testing will be easier | |||
====Inconvenient:==== | |||
*Instead of 4 or 5 minor releases only 2 will be scheduled | |||
<pre>There is NOTHING preventing us to do more minor releases if we have people taking care of them, | |||
exactly as it happens right now (we have had un-scheduled .5 and .6 releases)</pre> | |||
=== Translators === | |||
While there will be only one month to translate new or modified strings, the amount of changes in every release can be expected to be minor as well. | |||
Latest revision as of 01:34, 10 July 2013
Releases from KDE SC 4.12 and beyond
Motivation
The main motivation for this change is to reduce the amount of time between releases and make them simpler, making us able to deliver new features faster to our users while keeping if not improving the current quality.
Proposed changes
The time elapsed between big releases (4.12, 4.13, 4.14...) will be of 3 months (instead of 6) having the following structure:
- Two month for merging features
- One month to prepare the release
Tentative schedule for 4.12
- Start of development: July 10, 2013 (Potential moment of 4.11 branching)
- During this time merging of STABLE features is allowed
- Branching of 4.12: October 15, 2013 (Two month after 4.11 release)
- Beta 1 is created ASAP
- Strings are frozen
- Dependencies are frozen
- Artwork/Bindings frozen
- API frozen
- Release candidate: October 30, 2013 (2 weeks after Beta 1)
- Release 4.12 final: November 15, 2013 (One month after 4.12 branching)
- Release 4.12.1: December 15, 2013
- Release 4.12.2: January 15, 2014
Tentative schedule for 4.13
- Start of development: October 15, 2013 (Branching of 4.12)
- Branching of 4.13: January 15, 2014 (Two month after 4.12 final)
- Release of 4.13 Beta
- Release candidate: January 30, 2013
- Release 4.13 final: February 15, 2013 (Three months after 4.12)
- Release 4.13.1: March 15, 2014
- Release 4.13.2: April 15, 2014
In a picture
Freezes
All the freezes will be effective the day of the branching, this include:
- String freeze
- Dependency freeze
- Feature freeze
- ...
Maintainers
Since we will be decreasing the amount of time for testing, it is specially important that only features that are reviewed and stable are merged into master. Saying it in another way master should be always in a state where we can make a release from it.
If you had plans for 4.12 already, keep them! Even though 4.12 would be released 3 months sooner than it was planned, 4.13 will be released around the time (Mid Jan/Feb 2014), so no need to re-adjusts already made plans. Said it in another way, instead of having 1 release of 6 months we are having 2 of 3.
Developers
Not much changes besides the fact that releases become way simpler since we'll have 1 freeze day where everything will be frozen, instead of having different days spread across the release cycle.
Additionally missing a freeze becomes less important since releases will be done more often.
Distributions
Benefits
- Since we have shorter release cycles it is more probable that distros will be able to pick up more recent version of KDE SC
- Master will be always in a releasable state
- Cycles with less changes, will have less bugs
- Since cycles will have less changes, testing will be easier
Inconvenient:
- Instead of 4 or 5 minor releases only 2 will be scheduled
There is NOTHING preventing us to do more minor releases if we have people taking care of them, exactly as it happens right now (we have had un-scheduled .5 and .6 releases)
Translators
While there will be only one month to translate new or modified strings, the amount of changes in every release can be expected to be minor as well.