KDE Core/ReleasesProposal: Difference between revisions
| Line 11: | Line 11: | ||
=== Things to take into account as a Maintainer === | === Things to take into account as a Maintainer === | ||
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. | 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. | ||
=== 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 releseable state | |||
Inconvenient: | |||
*Instead of 4 or 5 minor releases only 3 will be scheduled | |||
There is NOTHING preventing us to schedule 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) | |||
=== Tentative schedule for 4.12 === | === Tentative schedule for 4.12 === | ||
Revision as of 18:02, 3 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, 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
Things to take into account as a Maintainer
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.
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 releseable state
Inconvenient:
- Instead of 4 or 5 minor releases only 3 will be scheduled
There is NOTHING preventing us to schedule 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)
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 frozens
- 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
- Release 4.12.3: February 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
- Release 4.13.3: June 15, 2014
In a picture
