Revision as of 14:10, 25 February 2015

Long-term releases

We’ve managed to make 6-month releases
- No change in schedule time: we want to continue doing 6-months
- Modulo adjustments so we don’t release too close to vacation periods
Release process is improving
- Ability to do package creation much more quickly
- Unification of packages with enterprise/commercial will also reduce workload
How long should long-term releases be?
- More than every 2 releases
- Probably every 18-24 months (3 or 4 releases)
First LTS release should be either 5.3 or 5.4
- Digia wants to do a business check first and will let us know
- 5.3 is a good candidate because we focused on stability
Doing LTS buys us a few benefits:
- We can deprecate platforms and compilers after the LTS release
- Targets to be dropped as soon as feasible:
  - Windows XP
  - OS X 10.6
  - MSVC 2008
  - GCC < 4.6
Procedure:
- Bugs to be fixed should be security bugs, P0, P1
  - P2 can be fixed, exceptionally, if no workaround is possible
- Fix is applied to the LTS branch and then merged to the next releases
- Releases should be based on amount of changes made, like what we’re doing for 4.8

@@ Line 1: / Line 1: @@
+=Long-term releases=
+* We’ve managed to make 6-month releases
+** No change in schedule time: we want to continue doing 6-months
+** Modulo adjustments so we don’t release too close to vacation periods
+* Release process is improving
+** Ability to do package creation much more quickly
+** Unification of packages with enterprise/commercial will also reduce workload
+* How long should long-term releases be?
+** More than every 2 releases
+** Probably every 18-24 months (3 or 4 releases)
+* First <span class="caps">LTS</span> release should be either 5.3 or 5.4
+** Digia wants to do a business check first and will let us know
+** 5.3 is a good candidate because we focused on stability
+* Doing <span class="caps">LTS</span> buys us a few benefits:
+** We can deprecate platforms and compilers after the <span class="caps">LTS</span> release
+** Targets to be dropped as soon as feasible:
+*** Windows XP
+*** OS X 10.6
+*** <span class="caps">MSVC</span> 2008
+*** <span class="caps">GCC</span> &lt; 4.6
+* Procedure:
+** Bugs to be fixed should be security bugs, P0, P1
+*** P2 can be fixed, exceptionally, if no workaround is possible
+** Fix is applied to the <span class="caps">LTS</span> branch and then merged to the next releases
+** Releases should be based on amount of changes made, like what we’re doing for 4.8