Which is the better release model for an operating system? It depends on your goals, including security.
A release model for a software system, such as an operating system, is the process and concept for how new OS versions are defined, produced, and released to the world. Parts and parcels of that are the development model and the “business” model for the software distributor. The development model is the process and concept for how software is developed; in the term “business model”, the word “business” is quoted because for many software systems there is no real commercial model underlying distribution. There are two major release models for an operating system that concern us here:
- By far, the most common is the point release model. In a point release model, a new version of an operating system — with all its included, core userland applications, such as shells, basic admin tools, and default text editors — is developed over some period of time, tested, finalized, and stamped with a version label. That version is then released to the public: FreeBSD 7.2, Microsoft Windows Vista, Apple MacOS X 10.3, and so on.
- A much more rare approach is the rolling release. In a rolling release model, parts of an OS are enhanced, advanced, or otherwise upgraded as needed, and the upgrades are made available to users without requiring a complete OS upgrade as in a point release. No commercial, general purpose, modern desktop OSs come to mind as examples of the rolling release model. In fact, no open source software of that variety comes to mind either, at least for the primary release model. Debian Unstable and FreeBSD-CURRENT are both rolling releases, but each of them serves primarily as a way to test software before including it in a point release version of the respective OS project (Debian Stable and FreeBSD-RELEASE).
Each of these models has advantages over the other, for users, developers, and distributors (including commercial vendors). Much of the reason that rolling releases are not common for consumer OSs is the fact that the traditional business model for such software systems involves the productization of software — treating software deployments as mass-produced, tangible products that are purchased in discrete units. Because of that productization, it is only natural to treat an operating system largely as a “finished product,” to be replaced every few years rather than upgraded on a constant basis.
By contrast, a rolling release is, in general, a software system that is upgraded on a fairly constant basis. Rather than working out all the details of a coherent package to be distributed to users as a new discrete replacement unit every few years (or, in the case of rapid release systems like Ubuntu, perhaps every few months), a rolling release involves developing a new feature, a new piece of core functionality, a new extension, or a new component, testing it thoroughly, then releasing that single update as soon as it is finished and stable, as an installable update to the system.
Some of this already occurs even in OSs such as MS Windows (see those “hotfixes” in your Add/Remove Programs list), but the purpose of these updates is generally to solve problems that simply cannot wait for the next point release. It is not intended to replace a complete system upgrade; MS Windows XP Service Pack 3 exists to keep people happy enough with what they have until they feel enough pressure to upgrade that they move on to MS Windows Vista, or 7, or whatever comes next.
Many users choose a rolling release intended for testing purposes and employ that as their primary OS. Debian Unstable and FreeBSD-CURRENT are selected for primary desktop OS purposes by many people, and serve well in that role for them, despite the warnings from the Debian and FreeBSD projects that they are not intended for such use. Some of these users may simply enjoy tinkering, or may feel a desire to help the project by employing testing systems in real-world use so they can provide meaningful and important bug reports. Some may not even realize they are using unstable software, having adopted that system as an improvement over an even less stable OS. Some, however, simply feel that the benefits of a rolling release outweigh the detriments of using a system still in a non-final, testing stage of development, much like the many people who started using applications such as Google’s Chrome browser and Gmail service.
The most common place to see what amounts to a rolling release model is probably Web applications, which are quietly upgraded, feature-by-feature, behind the scenes while people use it. Many users, for instance, may never have noticed the change from Gmail defaulting to unencrypted logins to defaulting to complete session SSL encryption.
The developer’s perspective
For development purposes, any number of factors can contribute to one or the other of point release or rolling release models being the easier to manage. Part of the reason the rolling release model is so popular for Web applications is the fact that there is no need in hosted service deployments to get user buy-in to a new product in order to maintain revenue streams. Whatever the business model, it is unlikely to involve maintaining many different variants of the software simultaneously, with people buying into the next version when they feel sufficiently pressured to do so. It is much easier and cheaper, when the provider has to maintain the running software, to maintain a single (most recent) version of it for everyone at the same time, and use a business model that is compatible with the rolling release model.
Point releases, by contrast, allow a bureaucratic organization to keep development under some kind of ordered management. A rolling release model requires far more organizational flexibility than is typically available in monolithic bureaucracies, and hierarchical management of such organizations is extremely difficult when the organizational structure within that hierarchy must change often to meet the needs of a rolling release model. More distributed, less hierarchical development organizations, as in some open source development projects, are better able to adopt a flexible — almost ad-hoc — structure that lends itself better to a rolling release model, but even they tend to self-organize at their cores into hierarchical structures a lot of the time.
Software testing can suffer in organizations that produce software on a point release basis, particularly if they focus heavily on release deadlines. Such release processes often lead to death march development and too much required testing in too short a time span. The sudden introduction of many new features and other changes to the system in a new point release requires more than just testing of each of the changes; it also requires testing of the interactions between all the changes. By contrast, in a rolling release model, changes typically happen one or two at a time, and testing per update is much simpler, in part because the parts of the system that may be affected by a given change are much more easily identified.
The user’s perspective
Users’ needs are met differently for each of these release models. In the case of the point release model, there are greater assurances of the stability of interactions between parts of the system (assuming the release is thoroughly tested), because updates in a rolling release might change the behavior of key parts of the system in unexpected ways, where they probably would not in a strict point release model because changes to system behavior other than bug fixes are generally not deployed between point releases.
The example of the deployment of MS Windows XP’s Service Pack 2 was a great example of where people relying on the assumption of a point release model were given a bit of a taste of a (very poorly managed) rolling release approach to upgrades, with a lot of software malfunctioning or failing to function altogether after the service pack upgrade.
On the other hand, under a point release model, upgrades are inherently disruptive. The major reason MS Windows XP Service Pack 2 caused so many problems is that it had many of the characteristics of a point release, but was sprung on unsuspecting users in the manner of a rolling release update: users were still using the “XP” release of the OS, whatever that meant to them, but under the hood there were sweeping changes, both broad and deep, to the way the system functioned.
With a rolling release, surprises tend to be much more minor, much more isolated, and much more easily fixed or worked around. They can also typically be more thoroughly tested at the deployment level as well, before they need to be deployed across an organization. In an explicit point release, meanwhile, one either risks everything by doing an in-place upgrade to the new point release (and possibly losing all configuration and data if something goes wrong) without even any guarantee that one will have a working system afterward, or one essentially installs a new system from scratch and migrates data from the old system. This can potentially lead to long nights of fighting fires and frustration over things one forgot to copy to the new system.
The security perspective
Security in particular, as a concern, shows some interesting effects of the choice between these two release models.
Expectations of change
The rolling release model has the problem of regularly imposing new behavior in small ways on the security conscious system administrator or user, which can become difficult to track for purposes of managing and securing the system on an ongoing basis. The point release model, meanwhile, dumps many — perhaps millions — of changes on the sysadmin or user all at once, requiring a complete restructuring of the security model for the system, and perhaps many sleepless nights of cramming to get up to speed quickly. Even if we ignore for the moment the problem of new vulnerabilities cropping up (but only for the moment; see below), this can cause problems for sysadmins who have not considered some aspect of how these changes can affect the security provided by their deployment configurations.
With a point release model, a system administrator or user installs a system, and installs security updates as needed. Because there is an expectation of the software system being in something like a “final” state, it is expected that changes will fix vulnerabilities, and introduce new vulnerabilities only in very rare cases. Because a rolling release introduces changes to the system for many reasons over its life, some of these might be intended as totally unrelated to security, but have the effect of introducing new vulnerabilities that in a point release model would only potentially appear with the introduction of a new point release.
On the other hand, a point release model ensures that such vulnerabilities occur in huge bunches, all at once, and they will likely be discovered spread out over a very long time — and there is likely no chance that they will (almost) all be discovered before the next point release. The kind of apocalyptic firefighting requirements this brings to mind for many sysadmins leads them to wait until after the first, or even second, service pack for a given MS Windows release before upgrading to the new point release. The potential for new security issues is generally much easier to deal with one item at a time, in cases where management of the system will be ongoing and attentive.
A development model built around a rolling release model is almost guaranteed to provide a better framework for quick reactions to vulnerability fixes. This is because, even in a point release model, the developers have to take something akin to a rolling release approach to dealing with vulnerability discovery and patching if they hope to avoid a reputation for slow and unreliable vulnerability fixing.
Part of the problem with Microsoft’s poor security reputation is its resistance to adopting a more fluid and flexible vulnerability response process with characteristics like a rolling release model. Vulnerabilities, unlike user features, are not eagerly awaited reasons to buy the new version. Instead, they are very immediate — and often frightening — reasons to stop using the current version of the software and choose something from a competitor who takes a more timely approach to fixing vulnerabilities. As such, projects more fully oriented toward a rolling release approach will tend to have a better process and set of procedures in place for dealing with vulnerabilities in such a timely fashion.
The release model used by the developers and distributors of a given operating system is only one of many factors that must be considered when selecting an OS. Unfortunately, the other factors involved usually trump the release model in importance, especially given that it is very difficult to find a non-testing version of an OS that provides a rolling release model. If one of your criteria is “must be a stable release”, you are almost guaranteed to be stuck with a point release model, no matter what your preferences.
For the most part, the choice of release model is at this point a matter for developers and distributors to consider, rather than users. When selecting a release model for your software, you should consider not only what is easiest for you (or your organization) to manage, but also what is the most conducive to suiting your users’ security and workflow needs. For foundational, complex systems such as an OS, a rapid iteration point release model with short support times (say, six to eighteen months between point releases, with less than three years of support) is probably about the worst release model you can use for high availability server and desktop systems. It combines some of the high potential for regular disruption of operations you might expect from a rolling release with the high level of operational disruption you get from a point release.
Except in cases of single-purpose workstations and servers that do not require single-system longevity, a rapid upgrade cycle for a point release model provides the worst of both worlds. Long upgrade cycles, with long support for each point release, can provide excellent single-system long term stability when that is the primary requirement for a system’s release model; a rolling release is well suited to circumstances where the lifespan of a single system should be maximized without sacrificing access to up-to-date software versions, especially where the need to upgrade hardware regularly is particularly low.
For my own purposes, I would prefer a point release model with a lengthy support period and long term upgrade cycle for (most) server deployments, but a rolling release model for (almost) everything else, including my smartphone. Other concerns end up taking precedence, however, and as a result I find that I use an OS with middling-length support periods and upgrade cycle in a point release model for pretty much all system deployments. I have used different systems for clients, but the best choice for many purposes is often much the same as what I use myself.
Your mileage may vary.