Oracle’s new release model includes
  • Yearly new releases (and numbered according to the year) instead of a multi-year cycle. Most annual releases will be supported for 3 years and outlined in the Lifetime support policy document (see at the end of this post)
  • Quarterly Release Updates (RUs are already introduced and part of 12.2) 
  • Quarterly Release Updates Revisions (RURs are already introduced and part of 12.2)
The new release model applies to the Oracle database, Grid Infrastructure, and OJVM. But: Windows patching won’t change and will continue to use Bundle Patches.
The format for the release model is <year>.<update>.<revision>
  • <year> is the delivery year for the release and will start with 18c (the first release with the new model is expected in late 2017 or early 2018 and supersedes the original name 12.2.0.2. 19c is supposed to supersede the original name 12.2.0.3)
  • <update> stands for the RU level
  • <revision> stands for the associated RUR level 

Example:
Version
Release
RU
RUR
18.1.0
18
1
0
18.2.0
18
2
0
First Release Update
18.2.1
18
2
1
First Release Update Revision for RUs from the last 6 months

The following table shows differences between Release Updates (RU) and Release Update Revisions (RUR)
RU
RUR
Shipping date
January, April, July, October
January, April, July, October
extend the RU’s lifetime up to two quarters
Replaces
Bundle patch
Patch set updates (PSU)
Switching
Switch to RUR possible
(for switching scenarios see the example below)
Switch to RU possible
(for switching scenarios see the example below)
Security fixes
Yes
Yes
Regression fixes
Yes
Yes
Proactive functional fixes
Yes
No
Minor functional enhancements
Yes
No
Emergency one-off patches
Yes
No
Optimizer fixes that can change plans
Yes
(see Doc ID 2147007.1)
No
Deployment
specific to a particular annual release.
RUs are full patches
specific to a particular RU.
RURs are supersets of all RUs where the second field is smaller than or equal to the RURs second field.  You are not required to first apply a prior RU.
Oracle’s Release Updates (RU) and Release Update Revisions (RUR) timeline:
Jan 18
Apr 18
Jul 18
Oct 18
Jan 19
Apr 19
Jul 19
Oct 19
RU
18.1.0
18.2.0
18.3.0
18.4.0
18.5.0
18.6.0
18.7.0
18.8.0
RUR #1
18.2.1
18.3.1
18.4.1
18.5.1
18.6.1
18.7.1
RUR #2
18.2.2
18.3.2
18.4.2
18.5.2
18.6.2
RU
19.1.0
19.2.0
19.3.0
19.4.0
RUR #1
19.2.1
19.3.1
RUR #2
19.2.2
18.1.0 and 19.1.0 are planned without RURs.

Switching between RUs and RURs is possible as long as versions are cumulative of one another. Cumulativeness can be computed by adding the second and third number of the version for source and destination DB. The sum for the destination DB must be greater or equal to the sum of the source DB. Examples according to Oracle Doc ID 2285040.1
Source
Destination
Conclusion
18.2.2
sum of second and third fields is 2+2=4
18.5.0
sum of second and third fields is 5+0=5
Destination 5 is greater than or equal to source 4 so it is OK to move
18.2.2
sum of second and third fields is 2+2=4
18.3.0
sum of second and third fields is 3+0=3
Destination 3 is less than source 4 so a patch application error will be issued
18.5.0
sum of second and third fields is 5+0=5
18.4.1
sum of second and third fields is 4+1=5
Destination 5 is equal to source 5 so it is ok to move. Caution: you will go backward one quarter from a “high-priority non-security fixes” point of view. But you are still keeping the regression and security fixes
One-off emergency patches are still available with the new release model. The OOW 2017 presentation also mentions monthly “Release Update (RU) Incremental Drops” to accelerate stabilization during the early part of a release lifetime. All incremental drop content is expected to be included in the next quarterly RU.

The current release roadmap according to Doc ID 742060.1:


Further information: