Changes to a well-known release model mean a lot. I will give you some of my thoughts about the new Oracle Database release schedule.
What are we changing?
In my own words we basically rename the patch sets and name them what they were since years: Full releases. This means, Oracle Database 12.2.0.2 will be Oracle 18. And Oracle 12.2.0.3 will be Oracle 19. And so on.
Therefore there won’t be any Oracle 12.2.0.2 anymore – and obviously no Oracle 13.1 followed by Oracle 13.2.
In addition we change from Proactive Bundle Patches (BP) to Release Updates (RU) and from Patch Set Updates (PSU) to Release Update Revisions (RUR).
You will find more information here:
- More Information about RU and RUR patches for Oracle 12.2
- News about the new Oracle Database Release schedule
My thoughts about the new Oracle Database Release Schedule
I’m happy. Not entirely (stereotype says, Germans are never entirely happy no matter what happens) but pretty happy. I was discussing the insane “first” and “second” release topic for years. Not only with customers but also internally. And I know that DBAs and IT architects had the same issues when they tried to promote an Oracle release to be rolled out internally. There was always somebody somewhere who said:
“Well, but we’ll go live on the second release only. We do this since the early middle ages. And we will continue doing this until the first human will step on Mars. Period.”
I can’t tell you how often I’ve heard this. And it didn’t help much when I tried to explain that SAP (yes, SAP!) certified Oracle 12.1.0.2 quite early and long before many others on March 31, 2015.
It didn’t help much either when I explained that things have changed since Oracle 11.1 (which in my humble opinion was more a 10.3 than an 11.1 – most of the big changes came with 11.2). It didn’t help when I showcased cool customers such as Die Mobiliar from Switzerland who went live entirely on 12.1.0.2 with almost 300 databases in 15 months.
There is always somebody in the room saying: “Yes, we believe you. But we’ll go live on the second release …“. Twitter is a wonderful resource for such comments.
There are no patch sets anymore
Patch sets are full releases. Patch sets were full releases for years. In Oracle 12.1.0.2 (a so called “patch set” containing a high number of fixes on top of 12.1.0.1) we introduced complete huge and important new features such as Oracle In-Memory. 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.
That is the reason why we move away from the term “patch set” and name it was it is: A full release.
And to mark this change visible for everybody we rename them using the year as the release number. There won’t be an Oracle 12.2.0.2 anymore. It will be named Oracle 18. And it will be followed by Oracle 19. And so on. You won’t see the term patch set anymore. It will be “release” and you can add “release updates” (which I’d highly recommend) and/or “release update revisions” to it.
This will hopefully end discussions. Nobody has to justify to go live on the first release. There is no first release. And there weren’t first release for many years. It were full releases.
So yes, I’m happy with this change. And it makes a lot of sense.
In addition please have a look into MOS Note 742060.1 – Release Schedule of Current Database Releases which gives you the official details and has information about proposed support timelines including a overview graph as well.
And you may also read Tim Hall’s thoughts as an independent Oracle ACE Director about the new release scheduling:
–Mike
Hi.
I’ve amended my post in this subject, now we have the clear definition of the process. I think my pros and cons are still valid on this. 🙂
https://oracle-base.com/blog/2017/07/14/oracles-new-release-cycles-my-thoughts/
Cheers
Tim…
I did link your thoughts, Tim
Cheers
Mike
The new features introduced in 11.2.0.4 were significantly fewer and less important than the ones introduced in 12.1.0.1 so you can’t say that both release 11.2.0.4 and 12.1.0.1 have the same impacts and that it’s the same effort for migrating to one or another.
That’s why I’m not happy with this new numbering method
Christian,
I know what you mean – but I disagree to some extent as I have seen many upgrades from 11.2.0.3 to 11.2.0.4 where the expectation was: that’s a minor step and just a patch release. Actually the effort from going to 11.2.0.4 to 12.1.0.1 or 12.1.0.2 was exactly the same with zero difference as the changes were visible in many ways. I won’t elaborate this further here but it’s based on experience and some knowledge 😉
Cheers
Mike
LOL, I admit that it might be confusing for the customers…
In Doc ID 742060.1, the graph shows that Release 18 will be supported for 3 years, whereas Realease 19 will be supported (PS + ES) for 6 years. So not all releases look equal (at least in this transition).
The doc also states:
“The current plan is for Oracle Database 19 to be the last release for 12.2. This may change in the future to Oracle 20 as the last release for 12.2.”
One might think: “so Oracle Database 21 will be the first release of 13.1?”
I understand Oracle’s move, but I think that the support must follow the same paradigm. e.g. having ALL the new releases supported for an equal period of time (e.g. 4 premium, + 3 extended).
Just my 2 cents.
—
Ludo
Hi Ludovico,
I see your points – and I just can guess that this may have to do with commitments we have given in the Lifetime Support Policy. You can’t just change those within a given release. And again, I’m just guessing 😉
The release numbering reflects now the reality of our releases – which is actually very good. But I know it will of course take some time until things are settled. And we’ll see what will happen to the support cycles in the future.
Cheers
Mike
Is this an April fool’s joke? Hang on it’s not April!
This makes no sense.
Simon,
I think it makes a lot of sense – and it reflects the release reality instead of displaying a “one” and “two” release numbering which didn’t exist anymore for quite a while.
Cheers
Mike
> …since Oracle 11.1 (which in my humble opinion was more a 10.3 than an 11.1 – most of the big changes came with 11.2)
Perfect! I think the same, but you expressed this in a perfect sentence!
I wonder what changes this will entail in the certifications program. Imagine having every year a new OCA, OCP or even OCM! But I agree there is no sense on this 2nd digit release number and even on the 4th patchset as sometimes it represents so many changes that could be called as a new release or version.
Rodrigo,
I think the people working in the certification program are thinking about this already. I’d just guess that it will take until the release cycle is really embedded until anything in the certification program will change. But I’ll forward your question internally as I know this is very important to OCPs and OCMs.
CHeers
Mike
I understand, but I will never go live on odd release, only on even one 🙂
We always did this in that way 🙂
Soon there’s no difference between odd and even anymore …
Cheers
Mike
Just admit: it’s all done to avoid the ‘unlucky’ versions 13 and 14
🙂
I don’t think so … if you’d start avoiding any unlucky numbers in a global product you’ll end up with 10 potential release numbers in the first 100 digits I’d guess 😉
Mike
Hi Mike,
I think Oracle goes to the right direction with the introduction of yearly releases but it’s not enough to be fully satisfying.
Do you know if after a transition period the complex roadmap will switch to a X years period of patching guaranteed for each release ? Ideally X would be >= 5 if Oracle wanted to be as efficient as a well-known open source product.
If it is not the case be sure people will wait for the terminal/LTS release as they were waiting for the final patchset.
Such a change would give your “Upgrade your database now !” far more power. People would have no reason to wait for the blessed version anymore.
I mostly work with SE2 customers and it’s particularly true in their case since their motivation to migrate is almost only support/security.
Best regards
Philippe
Hi Philippe,
I see your point, and I agree with you. But it’s too early to talk about releases after Oracle 19.
We’ll see how the roadmap will look like after 19 when 19 is available I’d guess 🙂
Cheers,
Mike
Personally I don’t like the new change on release naming.
The release naming does not show the release branch relationship across different releases.
If Oracle 18c is actually refers to ‘12.2.0.2’, but you won’t know it by looking at ’18c’.
Is Oracle 19c refers to Oracle 12.2.0.3 or Oracle 12.3 or Oracle 13? Is it a major release or release based on Oracle 12?
Ultimately people need to check and write down the version relationship between Oracle 12c/18c/19c/20c and etc.
Kai,
please see the release model slides on the SLIDES page of the blog.
This should answer your questions.
Cheers,
Mike
Hello Mike,
After reading your blog about 18c I still have some question marks regarding this new Release Schedule.
In the past there was no question about which release to install for a client which wanted to upgrade their current Oracle database platform to the latested release (11g/12c). In that case we always advised to install the second release with the latested patchset for instance 11.2.0.4.0. In the current setup this causes for a lot of discussion particularly with software companies as they often just have certified there applications on 12.2 so if we then advice to install 18.(1/2/3/4/5) this leads to discussion which we didn’t have in past.
What is your advice, should we tread 18 and 19 as a different release, with the needed certification from the software companies or can we regard them as “normal” patchsets on 12.2?
Cheers,
Wierd
Wierd,
according to MOS 742060.1 we are honest and say Oracle 18c is nothing different than 12.2.0.2 and Oracle 19c is the terminal release of the 12.2 family and the same as 12.2.0.3. Hence, no difference to previous releases except for the fact that we don’t “sell” a patch set as if it would be a simple patch. A patch set, for instance 12.1.0.2, contained not only far over 10000 fixes over 12.1.0.1 but also key features such as Oracle In Memeory or Optimizer Adaptive Feeatures.
Hope this helps – if not, let me know please.
Cheers,
Mike
Thanks Mike.
In that case we are going to implement 19c, when released for on-premise, as our “standard” patchlevel for clients who want or need to upgrade there current 11.2 or 12.1 databases to Oracle 12.2.
Cheers,
Wierd
Wierd,
that’s what I would recommend to you as well.
Thanks,
Mike