ReleaseCadence

Differences between revisions 23 and 32 (spanning 9 versions)
Revision 23 as of 2013-03-07 17:06:04
Size: 9003
Editor: lool
Comment:
Revision 32 as of 2013-03-08 01:06:18
Size: 4015
Editor: vorlon
Comment: clarify the update cycle for 6-month releases
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * LTS releases every ~ 2 years (8.04 -- only on the server, 10.04, 12.04); Ubuntu Desktop is only supported for 3 years though  * 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
Line 20: Line 20:
= Proposed rolling release + monthly updated release scheme (Rick Spencer) = = Proposed rolling release + monthly updated release scheme =
Details on the
ReleaseCadence/RollingRelease sub page.
Line 22: Line 23:
[[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. == 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
Line 24: Line 29:
An initial proposed implementation was captured in the [[https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-monthly-snapshots|foundations-1303-monthly-snapshots blueprint]] -- see diagram below
{{attachment:raring-with-monthly-updates-copy.png|raring with monthly updates copy|width=60%}}
== 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
Line 27: Line 34:
Benefits:
 * fresher software in the hands of users thanks to monthly releases
 * less releases to deliver SRUs on
== 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
Line 31: Line 39:
Drawbacks:
 * no 13.04 and 13.10 series with 18 months of support
= 6 Month Releases =
Details on the ReleaseCadence/SixMonthInterimRelease subpage.
Line 34: Line 42:
= Adding more pockets (multiple proposers) = == Summary ==
Continue to release interim releases but only support them until roughly the next interim release 6 months later.
Line 36: Line 45:
Various people have proposed adding pockets. This is somewhat intrusive in that Launchpad knows about pockets in a bunch of places. Adding a new set of pockets would be doable, but managing a varying list of pockets (pockets added/removed each month or to create new staging areas) would require a *large* amount of Launchpad engineering. == 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
Line 38: Line 50:
= Launchpad derivatives = == 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
Line 40: Line 55:
[[https://dev.launchpad.net/LEP/DerivativeDistributions|Derivatives Distributions]] is a Launchpad spec to deliver a mechanism for creating arbitrary derivatives of Ubuntu (source or binary subset based on package sets). = True Monthly Releases =
Details on the ReleaseCadence/TrueMonthlyReleases subpage.
Line 42: Line 58:
Unfortunately, implementation is incomplete and crude and would require a *large* amount of Launchpad engineering to complete. == 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.
Line 44: Line 64:
= More frequent releases (multiple proposers) = == Benefits ==
 * Fresher software in the hands of users
 * Fewer stabler releases to support conserves engineering efforts for current development
Line 46: Line 68:
Speed up / automate further the creation of new Ubuntu releases (series).

This is currently a costly operation in terms of release engineering time, means going through various freezes, updating a bunch of packages and locations and seems out of reach in the short-term.

= More point releases =

Deliver frequent point releases with a more open SRU policy allowing new software versions.

Backport latest desktop bits to latest stable release and update installation media monthly as we do for 12.04.2 etc.

= other proposals to be added here =

(Add your own proposal in a new section here.)

= Q&A =

As a result of his proposal, Rick Spencer attracted a lot of questions and offers some answers in Q&A form below; add your own questions and answers (with signature) below.

== Isn't the proposal you made a foregone conclusion? Wasn't it really a plan pretending to be a discussion? ==

 * [rickspencer3]
    No, I really did mean for it to be a discussion and approbriate governance to determine how, if at all, we would take up such a proposal. I have passionate views on the topic, and I tried hard to make the argument for those views. I sincerely hope that the discussion causes us to do the right thing, but where "the right thing" could be something very different than what I specifically proposed.<<BR>>
    I think the straw man proposal was a good one based on a good analysis, but I never thought such a change would be made without proper Ubuntu governance.

== So everyone but developers would use the LTS? ==

 * [rickspencer3]
    That is not how I envisioned it. I think that whoever uses LTS today would continue to use the LTS if they want. Whoever uses Interim releases would use the non-LTS version. Many people who use the non-LTS release do so because they like getting fresh software with new capabilities, but they won't tolerate their system breaking signficantly. So, non-LTS for tech enthusiests and developers only seems to be setting the bar for our daily quality too low. We should shoot for consumer-grade quality every day. I don't think we'll start out with that, though. But meanwhile, the interim releases are both a crutch (with their freeze periods) and take resources and focus that could be channelled into daily quality on the Ubuntu of the future. At some point we need to make the leap.<<BR>>
    This is a big shift in mindset that we only just started down. The product that we are building is the same product that users are using. But note that other software projects do this. Some are small, some are big. Some are on the web, and some are operating systems. If they can do it, so can we.

== Isn't this proposal just a proposal to go a 2 year cadence? ==

 * [rickspencer3]
    I think this perspective makes sense if we think that we cannot deliver enough quality between the LTS to make Ubuntu generally useful for people who use the Interim releases today. Otherwise, we will have monthly cadence for planning, and some users will use that cadence for updates. We will have a daily cadence for quality, though.

== Isn't changing our release heuristics incredibly risky? Won't we shed users? ==

 * [rickspencer3]
    Risk aversion is a personal thing. The risk I am worried about is that don't effectively shift our focus to creating a Converged OS and someone else will get there first. I think we should be marshalling all of our forces to gain that high ground, and shouldn't risk losing it because we aren't prepared to change the way we do things.

== What about flavors? ==

 * [rickspencer3]
    In my original mental model, this wasn't much of a problem. The flavors just use an LTS for their LTS users, and the non-LTS release for those who currently use the Interim release. However, my mental model was wrong, because this does not actually allow some of the flavors to address their mission. If their mission is to deliver a stable upstream every six months on a stable base, they won't have a new stable based every 6 months to build on.<<BR>>
    I think there are ways to ensure that flavors can continue to achieve their mission, but it won't be quite so simple. For example, they could use the LTS and use backports or PPAs heavily, maybe spinning a new release of the LTS whenever their upstream releases. They could snapshot the archive every six months and support it themselves, but I think this would be a very bad outcome. There would be few people supporting that snapshotted archive, and I think there is a lot of benefit to everyone working in the same archive.

== What would happen to people currently on 12.10? ==

 * [rickspencer3]
    I think some of them could simply update now, and then go along with us on the non-LTS release after that. I think for others, we would want to continue to support 12.10 until those users can reasonably expect to update to 14.04.

== Doesn't the change to not support 13.04 pull the rug out from under us? ==

 * [rickspencer3]
    On the one hand, I don't think we should fall into the fallacy of sunk costs. The fact that we had planned to release 13.04 in the normal way does not automatically make it the correct thing to do.<<BR>>
    On the other hand, some of the feedback was from people who were planning products and other economic opportunities from 13.04. For them, it's not a sunk cost falacy. Of course, any change we ever make to or support policy could have such an impact on people. But maybe the week of feature freeze is a bit close to the deadline to make such a call.

== What about OEMs that want to ship "fresh" Ubuntu ==

 * [rickspencer3]
    Except for a few exceptions, the larger OEMs all ship LTS and are planning to for the foreseeable future. I'm not clear why someone couldn't pre-install 13.04 today. It would go to users, it would update when they first turned it on, and they would be good to go.

== Isn't a Rolling Release just spaghetti code? Where is the rigor? ==

 * [rickspencer3]
    I think "rolling release" does have negative connations for many users. It might imply unpredictability, instability, and other undesirable aspects of software. However, I'm not certain how this is

== Is the Ubuntu 13.04 release cancelled? ==

== Will Ubuntu 12.04, 12.10 and other prior releases still be supported? ==
== 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

raring today

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)