What's your point, caller? Oracle fiddles with major database release cycle numbers ⢠The Register
Analysis Big Red has changed its database release cycle[1], scrapping names that see decimal points and numbers added on for an indeterminate amount of time, instead plumping for annual releases numbered by the year.
So what would have been Oracle Database 12.2.0.2 will now be Oracle Database 18; 12.2.0.3 will come out a year later, and be Oracle Database 19.
The approach puts Oracle only about 20 years behind Microsoft in adopting a year-based naming convention (Microsoft still uses years to number Windows Server, even though it stopped for desktop versions when it released XP).
In between the major versions, there will be quarterly release updates - bundles of critical fixes - and release update revisions - which will be security and regression fixes to a release update.
These will replace, respectively, proactive bundle patches and patch set updates, and are understood to be on the same patch schedule (January, April, July and October) as they are at the moment.
On the face of it, the move away from the long and complex numbering could be a good way of simplifying what an outdated and confusing system.
For instance, an annual full release should stop customers getting something half-finished in the first release.
It could also offer more predictability, compared with previous major database releases - Oracle Database 10 came out in 2004, 11 came out three years later, after which there was a six-year gap before 12 was released.
Great - where’s the catch?
Well, Big Red will surely be using the revamp as a way to boost sales of database licences - a crucial part of its business - which have been in decline for two years running.
In fiscal 2016, Oracle reported a 12 per cent drop in annual sales of new software licences, and its most recent results for fiscal 2017 revealed a further 5 per cent drop.
And, for all that Oracle has shouted about its cloudy success of late, it isn't yet a major money-maker for the biz. New software license sales make up a quarter of overall revenue, while support for that software makes up a further 45 per cent.
In part, the new numbering will be a handy marketing ploy. Rather than playing with the decimal points, a release with a new whole number could be an attempt to give the impression of agility in the face of younger, fresher competitors.
Meanwhile, fewer patches and releases on each system also allows Oracle to know more quickly, and more accurately, what security features each customer has. The annual numbering system is also a very simple way of telling you your system is old.
Although both will benefit customers, they also make for fine leverage to help Oracle flog more database upgrades - and dissuade people from trying to wait for the next-but-one version.
Whereas in the past it might have been easy to argue you were waiting for the second release, or next patch, now it might be more difficult to skip on 19 and hold out for 20.
“Eighteen, you say? Well, you’ll be taking a big gamble on security if you don’t go for 19 now…”
There’s also a legitimate question about stability - at the moment, companies might skip a release or two because their current system works and would rather not risk further issues by upgrading. Corporates that have spent a year or so testing that the latest software works with their applications and infrastructure might not relish the idea of doing it all again so soon.
Oracle will have to work hard to convince them that the quicker release cycles won’t bring with it less stability.
But some at Oracle argue that this isn't actually that much of a shift. Writing on his personal blog, Mike Dietrich, master product manager for database upgrades and migrations at Big Red, said that patch sets often bring in big changes anyway[2].
The shift between 12.1.0.1 to 12.1.0.2 introduced 13,000 fixes as well as “huge and important new features such as Oracle In-Memory”, he said, while 11.2 ushered in bigger changes than 11.1 (that was “more a 10.3 than an 11.1”, he said).
Instead, Dietrich argues that the real problem is one of education. “Patch sets became full releases since at least Oracle 11.2.0.2. But – and I fully understand this as we taught you – there was still this “first release plus one patch set, second release plus 3 patch sets” thinking.”
He finishes by saying: “This will hopefully end discussions.”
We’re not so sure. ®
References
- ^ changed its database release cycle (mikedietrichde.com)
- ^ said that patch sets often bring in big changes anyway (mikedietrichde.com)
- ^ The Joy and Pain of Buying IT - Have Your Say (go.theregister.com)
Comments