Comment: +1 for rapid releases

by Thorsten Leemhuis

Over the last two years, Firefox has demonstrated that releasing new versions at a rapid tempo offers many advantages and doesn't reduce quality. Its approach could offer a blueprint for other projects, such as KDE.

Over the last few years, the Linux kernel, Chrome and Firefox have clearly demonstrated that releasing new versions in quick succession works very well. Users get bug fixes quickly and new functions by and by, and in small doses, which are also easier for developers to manage. KDE would, in my opinion, be well advised to accept the proposal to halve (or reduce even further) the time between releases.

The biggest objection in the so far broadly constructive debate on the proposal has come from the KDE package maintainers at openSUSE, who claim that a faster cycle would mean more work and poorer quality. The fault here, however, lies primarily with the approach used by the openSUSE development team, with the KDE version included in any one version of openSUSE being fixed and subject to only minor updates. New versions containing major revisions have to be downloaded from optional package repositories. openSUSE 12.2, released ten months ago, consequently still uses KDE 4.8. Change-hungry users can find an add-on repository containing the current version of KDE, version 4.10, on the openSUSE Build Service.

This model not only complicates things for the openSUSE development team itself, it also makes life harder for KDE developers and for users. This is illustrated by reviewing the case of Firefox, which took a similar approach until two years ago, when, despite misgivings and some criticism, it switched to a rapid release process. Consequently a new version of Firefox is now released every six weeks. This is either the main Firefox development line (currently Firefox 22), which includes bug fixes and new features, or an annual extended support release (ESR) derived from it (currently Firefox 17.0.7esr). The ESR version is maintained for a full year and barely changes, being updated only with bug fixes and minor modifications.

Distributions such as Fedora, openSUSE and Ubuntu rely primarily on the main Firefox release, enterprise distributions such as Debian and RHEL tend to stick with the ESR version. As a consequence, Firefox developers are no longer directly or indirectly plagued by large volumes of bug reports for ancient versions included in some primordial Linux distribution. Instead the bug reports they receive largely pertain to the two development lines which are actually still being maintained. This improves collaboration between distribution and Firefox developers on maintenance and remedying bugs.

After some apocalyptic noises, developers of Firefox-related software have now adapted to the faster release cycle – good extension writers now know that a new version will be released every six weeks and adapt their extensions in good time. It doesn't always work perfectly, but it's better than it used to be, when it sometimes took weeks to months before even widely used extensions were able to work with Firefox 3.0, 3.5 or 3.6.

The Firefox development team has also become much closer to users – when they fix a bug, the fix reaches users within just a few weeks, and not, as used to be the case, months or years later, when a new version of their distribution delivered a new version of Firefox. New features also reach users faster and in smaller portions. This is important for remaining competitive in today's market and providing users with what they want quickly. The ease with which bug fixes can be applied over the web and through source code management systems such as Git permits a development model with no loss of quality – indeed it is often better than under traditional development models dating from the days in which software was still sold in boxes.

This could work just as well for KDE as it does for Firefox. A desktop environment may be more complicated, but rolling release distributions show that such updates do work. In Fedora too, large KDE updates have long been the norm. Fedora 17 originally shipped with KDE 4.8, but was later updated to version 4.9 and then 4.10, with no major problems.

Of course, revolutionary changes such as those introduced by KDE 4.0 should not be pushed out to users overnight. Such cases require a more conventional approach. The differences between, say, KDE 4.9 and KDE 4.10 are, as with successive Firefox releases, not normally so enormous that an average user would have trouble coming to terms with them; likewise GNOME and most other applications. Unlike ten or fifteen years ago, computer users must anyway get used to the idea that their environments will change a little over time. Elsewhere, this is now normal – smartphone and tablet apps rarely give users much choice over changes, web sites almost never.