R-1 is dead, long live R+45

Running release R minus 1? What about release R plus 45 days? We all know the Patch Tuesday update cycle where Microsoft releases their updates.

It is common practice for risk-averse companies to not run the very latest release of software, instead having a policy of running “R-1” – which for those who do not know, this means one release older than the most recent release. This can make an organization feel more comfortable that the code they are using to run their business is not using software that is not tested by time and could contain unknown bugs or flaws.

However, this may be more risky than people think. If there is a new release – particularly a service pack, patch or update – then this has been created to fix known problems. Running at R-1 will be using a version that may be known to have bugs and flaws, and almost certainly is missing new features and capabilities. The latest version is encouraged by software vendors and hardware vendors (for firmware and drivers) alike – but why are customers still insisting to be R-1?

It’s true that sometimes new releases will introduce a new bug or have a new problem. No company is immune to this, but other vendors are more prone to this sort of situation – that’s why there are mechanisms for providing updates to updates, that’s why Service Packs exist… Customers often are more frightened of the unknown and undiscovered bug than those which are shown as “known issues”. Huge effort goes into testing every new release, and when a bug does find it’s way through to customers, it’s all hands to the pump so that they can release a fix as quickly as possible.

So, when customers insist on running an older version of software, with known issues and problems, missing out on new features and capabilities – it’s disappointing. So many possibilities of better stability and performance not being fully realised by the people who need it the most – customers. It is not just for the Microsoft patch Tuesday update cycle, it also applies to other application updates.

R-1 is dead, long live R+45

So, a better approach would be R+45d, that is, running software that is the most current, but only if there are no updates, patches or releases for 45 days since the initial release. If the software has not had any critical issues where a patch is either announced or released, there are no people complaining about a problem in blogs or forums, then the software could be considered stable and suitable for implementation. Why 45 days? Some problems may only be found after a month-end type of activity, activities such as Patch-Tuesday when many VMs are rebooted, or the time for enterprises to go through their change control before implementation – and 45 days would cover this.