Ubuntu, Shuttleworth & rolling releases

After much heated discussion, Mark Shuttleworth has a new proposal on how Ubuntu Linux should handle rolling releases.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Canonical, Ubuntu Linux's parent company, has an ambitious plan with a short time-frame: One operating system for computers, smartphones, tablets and TVs by early 2014. One problem with this is how do you get there fast enough and one answer, rolling releases, has got developers upset. Now, Canonical and Ubuntu founder Mark Shuttleworth has a new proposal on how to handle rolling releases.

To get Ubuntu on PCs, TVs, smartphones, and tablets by next year, Mark Shuttleworth is looking for ways to speed up Ubuntu Linux development. (Credit: Ben Woods/ZDNet)

This issue of rolling releases, where major changes and improvements are released to users as soon as possible, combined with Canonical focusing on these forthcoming platforms and on the Unity interface, has really annoyed some Ubuntu programmers. Still as Jonathan Riddell, the team lead of Kubuntu, the Ubuntu version that uses KDE for its interface, said In a Muktware interview, "Canonical has upset quite a few contributors to Ubuntu Desktop by moving away from integrating community-made software like Gnome and developing their own.  While that has less of a warm fuzzy feeling for those of us who love community-made software, I don't blame them. Apple and Google have solved Bug No. 1 (Microsoft has a majority market share) while nobody yet has gotten near using community-made software. So it's quite reasonable to move to a new model."

And, how is this new model going to work? Well, Shuttleworth is proposing:

1. Strengthening the LTS point releases.

Our end-user community will be better served by higher-quality LTS [Long Term Support] releases that get additional, contained update during the first two years of their existence (i.e. as long as they are the latest LTS). Updates to the LTS in each point release might include:

  • Addition of newer kernels as options (not invalidating prior kernels). The original LTS kernel would be supported for the full duration of the LTS, interim kernels would be supported until the subsequent LTS, and the next LTS kernel would be supported on the prior LTS for the length of that LTS too. The kernel team should provide a more detailed updated straw man proposal to the TB [Technical Board] along these lines.
  • Optional newer versions of major, fast-moving and important platform components. For example, during the life of 12.04 LTS we are providing as optional updates newer versions of OpenStack, so it is always possible to deploy 12.04 LTS with the latest OpenStack in a supported configuration, and upgrade to newer versions of OpenStack in existing clouds without upgrading from 12.04 LTS itself.
  • Required upgrades to newer versions of platform components, as long as those do not break key APIs [Application Programming Interfaces]. For example, we know that the 13.04 Unity is much faster than the 12.04 Unity, and it might be possible and valuable to backport it as an update.

2. Reducing the amount of release management, and duration of support, for interim releases.

Very few end users depend on 18 months support for interim releases. The proposal is to reduce the support for interim releases to 7 months, thereby providing constant support for those who stay on the latest interim release, or any supported LTS releases. Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it.

3. Designating the tip of development as a Rolling Release.

Building on current Daily Quality practices, to make the tip of the development release generally useful as a ‘daily driver’ for developers who want to track Ubuntu progress without taking significant risk with their primary laptop. We would ask the TB to evaluate whether it's worth changing our archive naming and management conventions so that one release, say 'raring,' stays the tip release so that there is no need to 'upgrade' when releases are actually published. We would encourage PPA developers to target the edge release, so that we don't fragment the 'extras' collection across interim releases.

Shuttleworth is not proclaiming that this is how it will be. He carefully points out that this is "a new straw man proposal." Note – this is still just a proposal. I will ask the TB to respond to this one, since it incorporates both elements of Rick’s team’s analysis and feedback from wider circles."

Related stories

Editorial standards