Why Release Update Revisions (RUR) are tricky

A while ago we introduced Release Updates (RU) and Release Update Revisions (RUR). And despite the fact that not only we but also well known external experts such as Ludovico Caldara recommend to stay with Release Updates and simply ignore the Revisions, some people use them. There may be reasons for doing so. But in this blog post I will explain why Release Update Revisions (RUR) are tricky.

Photo by Michał Parzuchowski on Unsplash

Photo by Michał Parzuchowski on Unsplash

Differences between Updates and Revisions?

I tried to explain the differences between Updates and Revisions a while ago – and also compare them to PSUs and BPs.

And you may please read also this blog post explaining:

But why are Revisions tricky?

Not only I learned recently that some customers got the idea Revisions (RUR) would only contain security fixes. And hence, they decided to stay with Revisions. In a release terminology this means, you’d go from 18.3.1 to 18.3.2 to 18.4.2 to 18.5.2 and so on. This is technically possible.

But it has a very interesting effect you may not have taken into account. Let me show you a quick example.

This is a patching schedule for Oracle Database 18c:

Why Release Update Revisions (RUR) are tricky

Now we recommend to go forward with Updates (RU). This means you’d apply these patch bundles (or some of them depending on your patch frequency):

Why Release Update Revisions (RUR) are tricky

But what if you decide to go with Revisions (RUR) instead? Then your schedule may look like this:

Why Release Update Revisions (RUR) are tricky

Now you may ask yourself: And what is the tricky thing with RURs?

Well, until 18.3.2 everything looks fine as expected. You use:

  • The Update (RU) from July 2018 with
  • The Revision 1 (RUR-1) from October 2018 containing security and regression fixes from October on top of RU July 2018 and
  • Revision 2 (RUR-2) from January 2018 adding security and regression fixes from January on top of RU + RUR-1

So far, so good. But …

With 18.4.2 you don’t add just the security and regression fixes from April on top. This isn’t RU + RUR-1 + RUR-2 + “new security/regression fixes”.

With 18.4.2 you jump now from RU July to RU October. You add all the other content from October – and NOT ONLY the security and regression fixes.

Why Release Update Revisions (RUR) are tricky

This is important to understand.

And of course, the same jump will happen in July when you go to 18.5.2. Then you introduce the 18.5.0 Update from January automatically.

Why Release Update Revisions (RUR) are tricky

For me, this is clearly another argument AGAINST using Revisions unless Oracle Support clearly advises you to apply a Revision. You have this hidden jump from one Update (RU) to another. And as you will see this jump anyways, you should go with Updates only. There will be only 2 Revisions – there won’t be an RUR-3. Hence, this jump will happen when you stay with Revisions.

Stay with Updates (RU) instead.
Makes your life much easier.

–Mike

 

 

6 thoughts on “Why Release Update Revisions (RUR) are tricky

  1. Hi Mike,

    I recently saw an SR (3-18671026781) where support stated that “18.5.0 = 18.4.1 = 18.3.2 will be equal.” which sounded incorrect to me, and sounds different from what you’re saying here. Can you clarify? Am I misunderstanding? Or did support mis-state?

    Thanks,
    stephan

    • Absolutely incorrect – I will follow up with the SR owner.
      18.5.0, 18.4.1 and 18.3.2 will have the same security fixes – and the regression fixes in 18.4.1 and 18.3.2 will be in 18.5.0 as well. But 18.5.0 will have way newer and more fixes than the other two ones. And 18.3.2 is based on the July 2018 RU – but in January 2019 then.

      Cheers,
      Mike

  2. somebodies on oracle support tell to us that ru 18.5 will not be released. i tell to us that in year 2019 will have only 19.2 and that RU 18.4 is the last RU for 18C. It is true

    • Can you tell me the SR number please?
      This is TOTALLY incorrect for on-prem releases.

      The cloud tooling may be different – but the database RU in Jan 2019 will be 18.5.0.

      Cheers,
      Mike

  3. Hi Mike,

    Thank you for this blog post. This topic have been a topic of confusion on my end, and is glad to clear up some of the obfuscations I was unable to totally grasp.
    Are my assumptions correct that the RU’s are also cumulative like the PSU’s are? E.g. We recently updated an 18c DB from 18.3.0 to 18.4.0 without any issues. Would e.g. patching from 18.4.0 to 18.6.0 be possible, if we prefer a 6 month patch schedule for some setups?

    I also assume the RUs would be released as long as 18c is under regular support e.g. RU released in Q4 2020 or Q1 2021 would be 18.12.0?

    • Hi Daniel,

      yes, RUs and RURs are cumulative as PSUs and BPs were before.
      Hence, if you jump from RU 18.4.0 to 18.6.0 you’ll get 18.5.0 plus 18.4.0 and all previous RUs included automatically.

      And regarding release: yes, this is true as well. As long as the release is under bug fixing support.

      Cheers,
      Mike

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.