The Case for Cadence: Towards a Shared Release Cycle

Time-based release cycles have been extremely beneficial for free and open source software projects and the idea has caught on organically. Taking it to the next level, "meta-cycles" for projects and Linux distributions that consume all of the upstream projects, hasn't gone so quickly. In an effort to change that, Canonical's Mark Shuttleworth has posted an update on aligning Debian and Ubuntu package freezes, and hopes to inspire further conversations with upstreams around encouraging "cadence" on major releases.

The basic idea put forward by Shuttleworth is to have coordination between upstream projects and distribution vendors around the major releases of Linux distributions and the best work from the upstreams. This would allow the distros and upstream projects like the Linux kernel, GNOME, KDE, Python, etc., to focus on specific releases for long-term support. The existing situation is that the different Linux distros tend to ship different releases of the kernel, Python, Perl, GCC, and so on — which can make it a bit of a headache for the upstreams which receive bug reports and patches for a variety of releases. It also means that upstreams may not see their best work shipped and supported by the different distributions.

So far, cadence has not caught on in a major way. As Shuttleworth reports, Ubuntu and Debian did not achieve alignment on the feature freeze for Debian "Squeeze" and the next long term support release of Ubuntu (10.04) but they will share versions of several packages including the Linux kernel, GCC, Python, OpenOffice.org, and Perl.

Shuttleworth is calling for a two-year cadence for major releases, which happens to also be the cycle for Ubuntu LTS releases. Red Hat Enterprise Linux and SUSE Enterprise Linux tend to fall close to the two-year cycle, but not as formalized as Ubuntu releases. Fedora has releases every six months, openSUSE every eight months, and Mandriva features a major release each year with a minor update six months later. The major upstream projects vary from three-month cycles to whenever it suits the project to call a release good. In short, the herd of cats tend to move out of sync.

In theory, cadence is a fantastic idea. It's obvious that it would benefit Ubuntu, since they have settled on a two-year LTS release cycle. But it would also be good for the wider community and other distributions as well. If each of the major distros could agree to ship and support specific versions of the Linux kernel, GCC, Python, OpenOffice.org, and other major components, it could reduce headaches for upstreams and focus the energy of distro developers and reduce the amount of wasted work between distros. In practice, coordinating the major Linux distros and a multitude of key upstream projects is going to be fairly difficult without more community support behind the idea. To this end, Shuttleworth is calling on upstreams to start driving the idea:

If you're an upstream, kick off a thread in your mailing list or forums about this. Upstreams don't need to do anything different if they don't want to, we'll still just make the best choices we can. But embracing a two year cadence is the best way you have to be sure which versions of your software are going to be in millions of hands in the future – it's a great opportunity to influence how your users will experience your work.

For cadence to catch on, it will need to be driven by the major upstream projects or Ubuntu and Debian will need to show drastic benefits to lure the other major distro vendors into collaborating on the two-year cycle. There's not enough cohesion and cooperation at the distro level to drive something of this complexity, especially when it's something that might be seen as advantageous to a specific vendor. But it should catch on: predictable and shared release cycles benefit everyone from developers to the end users.