Oracle New Version Numbering

Oracle is using the same numbering scheme since I’ve started working with it (7.2). The 5 number scheme with the release number, patchset and PSU is quite confusing and the post I wrote about that (here) is still very popular.

But now, Oracle is changing that. They’ve decided to come up with a new and (hopefully) simpler system. The idea behind it is annual releases, when the version number is actually the release year. This should start from 12.2.0.2 release next year which will be named Oracle 18, while the planned 12.2.0.3 will be released the following year as version 19.

With this new system they’ve decided to change the concept of patchsets, PSU and CPU as well. From now on, in version 12.2 (versions 12.1 and older won’t be affected by this) we will have different patch concepts:

• Release Update (RU) – the main and larger patch. RUs will include highly tested patches for critical issues and might rarely include some new cloud features.
• Release Update Revision (RUR) – the smaller and more critical patch. RURs will include critical security patches and regression fixes and won’t include any new feature.
• The naming method for RUs and RURs will be <release>.<build_date>
• There will be no longer patchsets, patchset updates (PSU) or bundle patches (BP), only RUs and RURs.
• opatch will still be used to install RUs and RURs.
• Independent fixes will still be available for specific bugs

I have to admit that I’m not a big fan of numbering version that is based on the release year. The commitment is too high in my opinion. I guess Oracle saw that they actually release a version (patchset is practically a version) every year or so, but what happens if they have a huge version and decide to postpone it? Or something happens and they wish to release another version in the same year? Microsoft is doing this with SQL Server and Windows (some versions anyway, like Windows 2000, 2003, 2008, etc.), but I think it reduces the flexibility. I see no problem with version 12, 13, 14 and so on. Also, I don’t like the RU and RUR name (with the YYMMDD format). This is similar to CPU today, and I find it hard to remember the numbers. It was quite easy for me to remember that 11.2.0.3 was OK and 11.2.0.4 is very stable. I could even remember some bugs in specific versions and when they got fixed. There is no way I’ll be able to do the same with remembering the RU and RUR release date (not even year and month).

One great this about this new system is the elimination of multiple releases per version. Mike Dietrich wrote in his blog post that he is happy to get rid of the dual-release system for every version (like 10.1-10.2, 11.1-11.2…) and I completely agree. The history of this multiple releases for a version was quite a mess. Oracle 8i had 3 releases (8.1.5, 8.1.6 and 8.1.7), while many many new features were released with 8.1.7. Oracle 9.0.1 was awful and I remember Oracle saying not to use it for production, while 9.2 was great. Version 10.1 was not great, but 10.2 was excellent and as Mike wrote in his post, 11.1 was kind of 10.3. So as you can see, there is no definite distinction between the versions and releases within a version except superstitions whether we should or shouldn’t go live with the first release of the version.
One last though about the RUs and RURs. I noticed that the naming convention is identical for both, so I find it quite difficult to distinguish between them. If my database is 18.20180912, does it mean that I’ve installed an RU or RUR in September 2018? Do I have to know the release cycle for both to know that? I hope they will change that so it will be easier.
For more information you can look at MOS notes 742060.1 (release schedule of Oracle database) and 2285040.1 (info about the new RU and RUR)