Accelerating the JDK release cadence

Andrew Haley aph at
Wed Sep 13 17:21:05 UTC 2017

On 13/09/17 17:59, mark.reinhold at wrote:
> 2017/9/13 9:55:34 -0700, aph at
> From my blog entry (
>   To make it clear that these are time-based releases, and to make it
>   easy to figure out the release date of any particular release, the
>   version strings of feature releases will be of the form `$YEAR.$MONTH`.
>   Thus next year's March release will be 18.3, and the September
>   long-term support release will be 18.9.
> That's the proposal.  I'm sure there will be further discussion, but in
> the meantime we had to pick some number to use on the JSR submission, so
> it's "18.3".

Aha!  OK.  This numbering scheme is somewhat familiar to me from
Cygnus days in the form 99r2, i.e. Release 2 in the year 1999.  I
think that release numbering makes more sense than month numbering,
but that's a bikeshed down the road.  Having said that, my wife points
out that it's good to have the month number in there because it's
easier to understand: you immediately know when a release happened.
So I suppose I could be persuaded.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the discuss mailing list