ReleaseCadence
393
Comment:
|
← Revision 32 as of 2013-03-08 01:06:18 ⇥
4015
clarify the update cycle for 6-month releases
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
<<TableOfContents()>> | ||<tablestyle="float:right; font-size: 0.9em; width:35%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
Line 7: | Line 7: |
= Proposed rolling release + monthly updated release scheme (Rick Spencer) = | Currently we have: * LTS releases every ~ 2 years (8.04 -- only on the server, 10.04, 12.04); Ubuntu Desktop has 3 years of support for 8.04 and 10.04, with 5 years on 12.04 LTS * interim releases every 6 months * development release (currently raring) where next interim or LTS release is prepared -- see diagram below |
Line 9: | Line 12: |
= others proposals to be added here = | {{attachment:raring-today.png|raring today|width=60%}} |
Line 11: | Line 14: |
= Q&A = | Issues with current release scheme: * releases every 6 months are too far apart when compared with web and mobile standards (updates ~ every month) * lots of time spent on security updates and SRUs of many past supported releases * insufficient amount of testers of SRUs * insufficient quality checks of uploaded packages before they reach developers (raring-proposed to raring migration) |
Line 13: | Line 20: |
== Is the Ubuntu 13.04 release cancelled? == | = Proposed rolling release + monthly updated release scheme = Details on the ReleaseCadence/RollingRelease sub page. |
Line 15: | Line 23: |
== Will Ubuntu 12.04, 12.10 and other prior releases still be supported? == | == Summary == [[https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html|Rick Spencer proposed on ubuntu-devel@ a new release cadence]] dropping the interim (non-LTS) releases but adding monthly releases supported only until the next month. An initial proposed implementation was captured in the [[https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-monthly-snapshots|foundations-1303-monthly-snapshots blueprint]] * Stop making Interim releases * Migrate current users of Interim releases to what is essentially our current development release * Continue to invest in daily quality until the development release meets the same quality standards as an Interim release == Benefits == * Fresher software in the hands of users * Fewer stable releases to support conserves engineering efforts for current development and LTS point releases * Making the leap will force us to "learn by doing" to make our development release consumer grade == Drawbacks == * Questionable replacement for current release process (doubts about quality of a rolling release) * Difficult for some flavor communities to fulfill their mission without a stable base to ship on * Supporting the monthly snapshot requires new engineering efforts = 6 Month Releases = Details on the ReleaseCadence/SixMonthInterimRelease subpage. == Summary == Continue to release interim releases but only support them until roughly the next interim release 6 months later. == Benefits == * Not a radical departure from our current release cadence * Fresher software in the hands of users * Fewer stabler releases to support conserves engineering efforts for current development and LTS point releases == Drawbacks == * Software ages to six months old each release * Cost of doing release management each cycle * Users must update every six months to receive support = True Monthly Releases = Details on the ReleaseCadence/TrueMonthlyReleases subpage. == Summary == Can we make even MORE releases in a year? And can we automate that process to make it bulletproof for end-users? * Make the update process from point to point really bulletproof. Upgrading today is possible, but to keep the system clean over multiple successive upgrades requires an uncommonly high level of skill with APT. * Strengthen the definition of point releases in the LTS so that interim releases are obviously less relevant. * Do a reasonable amount of release management on, say, MONTHLY releases that they are actual releases rather than just snapshots. == Benefits == * Fresher software in the hands of users * Fewer stabler releases to support conserves engineering efforts for current development == Drawbacks == * Cost of doing release management each cycle * Users must update each month to receive support |
This page captures various proposals for changing the Ubuntu release cadence.
Current release scheme
Currently we have:
- LTS releases every ~ 2 years (8.04 -- only on the server, 10.04, 12.04); Ubuntu Desktop has 3 years of support for 8.04 and 10.04, with 5 years on 12.04 LTS
- interim releases every 6 months
- development release (currently raring) where next interim or LTS release is prepared -- see diagram below
Issues with current release scheme:
- releases every 6 months are too far apart when compared with web and mobile standards (updates ~ every month)
- lots of time spent on security updates and SRUs of many past supported releases
- insufficient amount of testers of SRUs
- insufficient quality checks of uploaded packages before they reach developers (raring-proposed to raring migration)
Proposed rolling release + monthly updated release scheme
Details on the ReleaseCadence/RollingRelease sub page.
Summary
Rick Spencer proposed on ubuntu-devel@ a new release cadence dropping the interim (non-LTS) releases but adding monthly releases supported only until the next month. An initial proposed implementation was captured in the foundations-1303-monthly-snapshots blueprint
- Stop making Interim releases
- Migrate current users of Interim releases to what is essentially our current development release
- Continue to invest in daily quality until the development release meets the same quality standards as an Interim release
Benefits
- Fresher software in the hands of users
- Fewer stable releases to support conserves engineering efforts for current development and LTS point releases
- Making the leap will force us to "learn by doing" to make our development release consumer grade
Drawbacks
- Questionable replacement for current release process (doubts about quality of a rolling release)
- Difficult for some flavor communities to fulfill their mission without a stable base to ship on
- Supporting the monthly snapshot requires new engineering efforts
6 Month Releases
Details on the ReleaseCadence/SixMonthInterimRelease subpage.
Summary
Continue to release interim releases but only support them until roughly the next interim release 6 months later.
Benefits
- Not a radical departure from our current release cadence
- Fresher software in the hands of users
- Fewer stabler releases to support conserves engineering efforts for current development and LTS point releases
Drawbacks
- Software ages to six months old each release
- Cost of doing release management each cycle
- Users must update every six months to receive support
True Monthly Releases
Details on the ReleaseCadence/TrueMonthlyReleases subpage.
Summary
Can we make even MORE releases in a year? And can we automate that process to make it bulletproof for end-users?
- Make the update process from point to point really bulletproof. Upgrading today is possible, but to keep the system clean over multiple successive upgrades requires an uncommonly high level of skill with APT.
- Strengthen the definition of point releases in the LTS so that interim releases are obviously less relevant.
- Do a reasonable amount of release management on, say, MONTHLY releases that they are actual releases rather than just snapshots.
Benefits
- Fresher software in the hands of users
- Fewer stabler releases to support conserves engineering efforts for current development
Drawbacks
- Cost of doing release management each cycle
- Users must update each month to receive support
ReleaseCadence (last edited 2013-03-08 01:06:18 by vorlon)