Version-string schemes for the Java SE Platform and the JDK (original) (raw)

Ben Madore ben at panderalabs.com
Thu Oct 19 19:42:48 UTC 2017

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

(A) Absolute: YYYYYYMM, padding the month number with a zero as needed, and YYYYYYMM.$AGE for update releases, where $AGE is the number of months since YYYYYYMM.

(B) Absolute: YY.YY.YY.M as proposed, without padding the month number, and YY.YY.YY.M.$AGE for update releases, where $AGE is as above.

(C) Relative: N,whereN, where N,whereN is the number of half-years since JDK 9 GA (September 2017) plus nine, and N.N.N.AGE for update releases, where AGEisasabove.(AGE is as above. (AGEisasabove.(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

More information about the jdk-dev mailing list