|
|
| 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> < 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
| |