Version-string schemes for the Java SE Platform and the JDK

[Ben Madore]

   On 19 October 2017 at 16:08,  <mark.reinhold at oracle.com> wrote:
  

   >  (A) Absolute: $YY$MM, padding the month number with a zero as needed,
    >       and $YY$MM.$AGE for update releases, where $AGE is the number of
    >       months since $YY$MM.
    >
    >   (B) Absolute: $YY.$M as proposed, without padding the month number,
    >       and $YY.$M.$AGE for update releases, where $AGE is as above.
    >
    >   (C) Relative: $N, where $N is the number of half-years since JDK 9 GA
    >       (September 2017) plus nine, and $N.$AGE for update releases, where
    >       $AGE is as above.  ($AGE is more useful than another incrementing
    >       counter since it leaves room for emergency update releases without
    >       having to renumber subsequent update releases that are already in
    >       development.)
    >
    > Examples of these alternatives, for the next two feature releases and
    > their first two update releases:
    >
    > Examples of these alternatives, for the next two feature releases and
    > their first two update releases:
    >
    >                                (A)       (B)       (C)
    >     GA (March 2018)            1803      18.3      10
    >     First update (April)       1803.1    18.3.1    10.1
    >     Second update (July)       1803.4    18.3.4    10.4
    >     GA (September 2018)        1809      18.9      11
    >     First update (October)     1809.1    18.9.1    11.1
    >     Second update (January)    1809.4    18.9.4    11.4
    >
    
What is the convention if multiple releases have to occur more frequently than the resolution of $AGE. That is, a month.  For instance if release the first update to 18.3 is 18.3.1 what happens if immediately upon release a major regression is found? This could not be 18.3.2 - unless it was artificially held to be released in May. Would it be 18.3.1.1?

-Ben