The latest release of Canonical’s innovative open source operating system, Ubuntu 12.10, maintains its twice-annual upgrade pattern. Even though the last few releases have generated a steady chorus of cries for longer release schedules, Canonical’s leadership stands by the schedule and the rationale behind it.
Canonical CEO Mark Shuttleworth certainly does not think Ubuntu’s every-six-month release schedule is part of any ill-perceived problem. During his recent Linuxcon keynote address, he praised that cycle for creating lots of excitement and keeping contributors motivated.
At least one of Canonical’s board members favors longer release intervals. Meanwhile, Shuttleworth steadfastly adheres to the mantra: Many eyes make all bugs shallow, so make releases early and often.
Contrary to the criticism, Ubuntu’s twice-yearly release cycle has a clear purpose for Canonical’s success as a major OS developer. It forms a cadence with several upsteams and other distributions, according to Adam Conrad, Ubuntu Release Engineer at Canonical. That helps the development team keep its fingers on the pulse of current open source development.
“We’ve put robust mechanisms in place to ensure quality, both with our own products and with various upstream products that we rely heavily on. Our focus on quality permeates from the platform up to the code we write upstream, and our choices of upstream components too. We require tests and gated trunks for all Canonical code bases and prefer upstreams that share the same values,” Conrad told LinuxInsider.
That explanation makes considerable sense, noted Al Hilwa, program director for applications development software at IDC. Fundamentally, it is an execution and planning issue.
“What is important is putting out a predictable schedule and a road map for when projected functionality will be integrated,” Hilwa told LinuxInsider.
Whether Ubuntu needs to adjust that cycle is the sticking point, however. The development team has to assess the nature of the code changes versus the intervals available to stabilize the code.
“In principle, most changes can be incrementalized to fit any cycle,” Hilwa suggested.
Extending the release cycle would not necessarily lead to better overall quality. Rather, it would only give people a longer goal to land the new features they really want to see, in Conrad’s view.
Another reason he disfavors a more relaxed release time is human nature. Ultimately, people will always try to get things in at the last minute.
“We do offer our LTS [Long Term Support] product on a two year cadence, and we invest significant resources into polishing our LTS releases both before and after they’re released to make sure they’ll be solid and maintainable for five years,” he explained.
A longer release schedule would have little impact on quality, Conrad added. Every release puts quality first these days. They all get used on the server and on devices.
The term of maintenance between regular and LTS might vary. Nonetheless, the company’s commitment to interim releases is just as important as it is to an LTS release, he noted.
Time may be less of a factor than management goals, offered Hilwa. The issues boil down to project management dexterity.
For example, a development team has to come to terms with the natural rhythm of evolution of its product with respect to the market requirements. Release schedules can then be worked out to accommodate these needs.
“Mature products are more easily delivered on a predictable schedule. New products with significant new investment can require irregular intervals, for example, to stabilize major changes,” Hilwa said.
Rhyme With Reason
The release cycle is often tied into the marketing plan of a Linux distro. Many Linux distributions have a regular release cycle. A few, such as Puppy Linux, only release new versions when the community has time to build in enough new features or make substantial bug fixes.
Fedora Linux follows a similar time frame to Ubuntu. A new version of Fedora releases every six months. But there is no LTS version. Maintenance for Fedora releases lasts 13 months. So users of a Fedora distro one year old needs to move on or be left behind.
So Canonical might gain traction for some personal users and lots of business adopters simply because they can coast along without orchestrating an upgrade deployment for two years when a new LTS version arrives.
Meanwhile, regular security and bug fixes are fed through the software management mechanism of the distro. Those who want the next new thing can upgrade sooner, even if they have skipped one or two release cycles.
Most of the more well-known Linux distros seem to avoid short-cycle releases. Besides Ubuntu and Fedora, the only major distro that comes close to sooner-than-later releases is OpenSUSE. That community issues a new release every 8 months.
Linux Mint uses an annual upgrade cycle, but it maintains recent generations for extended periods and preaches that upgrading is not necessary.
Red Hat Enterprise Linux, SUSE Linux Enterprise and CentOS upgrade every two to three years. Debian Stable comes out anew every three years. PCLinuxOS and Gentoo Linux follow an imprecise rolling release cycle.
Serving Two Masters
One of the big attractions of the Linux OS is its ability to play nicely with diametric user groups. The dual audience for Linux distributions pits the unpaid, community versions as a complement to the paid, subscription Linux users, according to Jay Lyman, senior analyst for enterprise software at The 451 Group.
“The dual audience seems to consist of those who want the latest and greatest features and functionality in a new version, new Linux kernel and other updated components and those seeking stability, reliability and commercial support,” Lyman told LinuxInsider.
In Ubuntu’s case the company’s regular, twice-annual releases satisfy the first group. Those are mostly developers. The LTS releases serve the second group, which includes large enterprises and service providers, he explained.
Long or Short: Is One Better?
Shorter and longer release cycles give fairly obvious quality versus shininess trade-offs, offered Conrad. Ubuntu’s developers try to balance both so as not to short-change either audience.
Ubuntu’s code-writers work hard to ensure that quality shines through on every release to give users access to the latest and greatest software and features, he said.
“Moving to even shorter cycles, while often heralded as the next best thing in software development, is not particularly realistic for a system as complex as a large Linux distribution,” said Conrad.
That would force Ubuntu’s team to spend so much working on the release processes and stabilizing inter-dependencies that the team would never actually get a chance to land many new features, he explained.
One Size Can’t Fit All
“What works well for development of smaller and self-contained software projects doesn’t necessarily translate well to releasing an entire operating system,” said Conrad.
In assessing the advantages over the disadvantages, there is no escaping the balancing act. It might require one part marketing and one part determination. In the end, the customer will walk away or stay.
“Fundamentally it is an approach that aligns the software release cycle with a faster pace of customer demand such as in a consumer cycle or to simply incrementalize software evolution in order to speed functionality to market or provide it in a more predictable way,” said Hilwa.
Fixed vs. Floating
Is such a fixed cycle necessary at all? After all, users can update or not at any time they choose. So what is the rationale behind the decision in the first place?
Fixed cycles — or, at least, fixed stable releases — are necessary for users who absolutely must have a baseline and stable system on which to develop their own solutions, according to Conrad. “For instance, being quirk-for-quirk compatible over a five-year period — in the case of LTSes — lets shops add their own internal ‘secret sauce’ to their rollouts without having to constantly update and track our development.”
On the other hand, single-desktop users can more easily follow a rolling release model, if they so choose, noted Conrad. Ubuntu is increasingly getting to the point where its development release is a product that is always in good-enough shape that even non-technical users can be confident upgrading it on a daily basis, he added.
Which Way to Go?
“We may not quite be there yet, and I’m not sure I’d recommend our development releases to people who aren’t occasionally prepared to file some bugs or deal with some oddities. But our goal is certainly to make this a viable option for people who don’t want or need stable releases,” Conrad concluded.
Generally, software product release cycles can be feature-based or schedule-based. Increasingly, Hilwa is seeing a shift to schedule-based approaches as technologies move to cloud provisioning in an attempt to provide continuous services.
Additionally, the fast pace of technology has driven many categories of software to schedule-based releases. That is especially true as more of the market shifts to the consumer side, which is governed by a distinct retail commerce cycle, said Hilwa.
Need For Speed
Clearly, the cadence of release in Linux and other open source software projects can be overwhelming for enterprises. Still, LTS and paid subscription versions of Linux provide greater longevity and less worry about updating, concluded Lyman.
“While open source software is being used more and more in the enterprise market, where you would expect longer release cycles, the overall trend in the industry is to iterate, update and release software more frequently. So I expect this duality to continue with both approaches retaining their advantages for different sets of users,” he said.