Why rolling updates are bad practice

Updates are inevitably good news, and bad news. The good news is that they may fix annoying bugs, and bring neat new features. The bad news is that they will also bring new bugs, and maybe break existing features.

For system administrators, updates bring work, sometimes lots of it. They need to check that the update will not cause problems, normally by running one or more test installations, and checking them out before making the decision to update live systems. During that, they will normally work out when and how to perform that roll-out so that it causes the least disruption possible.

The traditional software lifecycle, including periodic ‘point’ updates, evolved in IBM around sixty years ago. Although it worked well for software when it was sold on physical media, such as floppy then optical disks, it was equally applicable to updates provided in-house or within a network.

It was IBM staff who conceived the model of ‘alpha’ (A) releases, ‘betas’ (B), and the final release (C), with carefully defined quality criteria which allowed an update to pass from one stage to the next. Even so, from those early updates until now, there are innumerable instances of serious bugs which escaped into the final release.

Adobe CC subscribers will be only too well aware of this now, with Adobe’s recent and potentially catastrophic bug which removes the contents of the first-named hidden folder at the root level of your startup volume, detailed on Ars Technica.

This is bad enough when issued as a ‘point’ update. Cautious users will either do as a system administrator does, and test such updates out on non-production systems before installing them on a live production computer, or wait for others to find such bugs. Those of us who feel compelled to be early adopters get used to life at the bleeding edge, and recovering from such cock-ups using backups.

But imagine if Adobe had pushed that bug out to all users in an automatic, ‘rolling’ update.

Yet that is exactly the sort of catastrophe that software vendors are heading for. Already Microsoft Windows 10 and Office 2016, and other products, are moving over to a rolling update model, and some Linux distributions offer it as a feature. It is so tempting for vendors to try this, now that almost all software, from operating systems to little utilities, is distributed electronically.

In an ideal world, if software never had any bugs, it might work beautifully. But as users of Office 2016 and Adobe CC know only too well, some updates pull the rug from under you, and take away features or compatibility with other apps. Returning from lunch to continue work, it would be more that just disconcerting to discover that the feature which you had just been using has changed or vanished.

If vendors were to ask users what needed to be improved most in software updates, I can guarantee that two of the items close to the top of that list would be better pre-release quality control and testing to reduce the frequency and severity of bugs in updates, and better documentation of changes made in an update. Yet just recently vendors seem to have been failing on both those counts.

Apple’s OS X 10.11.3 update was quite large, and as I revealed here, contained a lot of changes across a large proportion of its components. Yet Apple has still not informed us of most of those changes, even a month after the update.

As for bugs in updates, we should ask how Adobe’s quality management processes ever allowed such a gross and obviously damaging bug into beta test, let alone out on release.

There are of course components which need to be updated frequently, and preferably automatically. Good examples are security whitelists and blacklists, the sort of things which are properly addressed using a different mechanism. OS X’s XProtect is a good illustration of how that should be handled.

The next time that any updater (or vendor) asks you whether you wish to install updates automatically, just say no, please. You will then be ensuring that we send a clear message to software vendors that we want them to do their job properly, not leave it to us to be their unwitting beta testers.