Release synchronization

One could quibble with this claim in a number of ways, but it is true that Ubuntu got out a release designed to be supported for a number of years, and they did it when they said they would. That, of course, is only part of the job; now they have to follow through on that little promise of supporting this distribution into 2011. The initial signs are good: Ubuntu's support thus far has been solid, and it would appear that the distribution will not be going away anytime soon.

One might well question whether the timely release of 8.04 is noteworthy. As a community we are increasingly spoiled; an increasingly large number of projects and distributions manage to get out regular releases on a reasonably predictable schedule. Even kernel releases, once known to slip for a year or more, are now predictable to within a couple of weeks. Now that free software releases are rather more predictable and reliable than, say, airline departures, why is the Ubuntu 8.04 release noteworthy?

The answer is the long-term support commitment. Theoretically, a distribution intended for this sort of long lifetime will have had a degree of extra care put into its preparation. Important components will have been given extra time to stabilize so that the distribution will be more reliable from the outset. Some thought will have gone into the selection of packages shipped with an emphasis on supportability over the long term. The whole process requires more effort and a higher degree of assurance that all of the pieces are truly ready.

The degree to which Ubuntu has done all of that work should become clear over time. Certainly the software selected for this release is rather less seasoned than the packages found in a Red Hat or SUSE enterprise release. But "older" does not necessarily mean "better" or "more stable," so the real proof will be in how well this distribution holds up for the next three years.

Meanwhile, Mr. Shuttleworth has already stated that the next long-term support release will be happening in April, 2010. Ubuntu's success with 8.04, he says, allows this commitment to be made almost two years in advance. There is, however, a possibility that things could change:

This idea is not new, but Mr. Shuttleworth seems to be particularly attached to it. There is no doubt that there would be advantages to aligning schedules in this way. The kernel developers, who have been known to make a special effort for a release destined to be used by a major enterprise distributor, could focus especially hard on a stable release knowing that it would be widely used. Higher-level projects could do the same. The distributors could also, perhaps, find a way to collaborate on the long-term maintenance of these components, rather than duplicating the effort of backporting patches into older code. Perhaps they could even get together for a joint release party, saving even more money.

Or perhaps this is all a nice idea which fails to survive its encounter with reality. Enterprise distribution releases tend to be highly-publicized events. Ubuntu might be happy to share its limelight with the larger distributors, but that feeling might not be reciprocated on the other side. It is hard to imagine Red Hat or Novell wanting to have their big enterprise distribution release be just one of many happening during the same month.

It is also hard to see Ubuntu making an agreement with the enterprise distributors which specifies both a release date and the versions of the major components. 8.04 released with the 2.6.24 kernel, which was almost exactly three months old at the time. Red Hat Enterprise Linux 5 released in mid-March, 2007, when the 2.6.20 kernel was current - but Red Hat shipped the six-month-old 2.6.18 kernel instead. Aligning schedules would require more than picking a date; it would also require adopting similar stabilization periods. It is far from clear that Ubuntu would want to fall that far behind the leading edge for the sake of alignment.

And, frankly, it's hard to imagine Debian making a credible commitment (within one month) to a release date at all.

So the aligned schedules for enterprise distributions seems like a hard sell. A better approach might be to try to wean these distributions off the "freeze and backport" model of support; this model is expensive to sustain, brings risks of its own, and doesn't always fit the needs of enterprise customers.. If the enterprise distributors were able to track more current software - rather than backporting pieces of it into older software - better alignment of releases might just come naturally.