Accelerating the JDK release cadence

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Accelerating the JDK release cadence

David Herron-2
First - this is excellent news.  I've been away from OpenJDK anything for
quite awhile, but news about this popped up on my radar and I'm happy to
see this decision.

A part of the announcement concerned working with OpenJDK partners on some
kind of test infrastructure.  Which touches into the ideas I'd been
concocting while still at Sun, and never got to implement.  Water under the
bridge for me, but I wish the best results for whoever gets to do it.

In any case, I have a couple items of feedback

> 2. Every product that has used time-based version numbers has inevitably
> dropped the approach (the only exception that comes to mind is MS Word).
> When this happens, the version history is permanently polluted with large
> version numbers. Instead of hijacking the major.minor version numbers,
> consider placing this information in the build number (e.g.
> 9.1.5+2017-11-15)

Please take a look at Node.js version numbering.  It is semver-compliant,
they're also on a 6 month release schedule, the version numbers are not
based on the year, and the version numbers do not become hideous.  For
example 6.11.3 is the most recent LTS release -- the 6.x train having begun
in April 2016.  In a few weeks the 8.x release train is scheduled to become
the LTS release train.  The odd-number release trains are used for
speculative development, the even number releases are used as stable
branches.

I see some are yammering for git to supplant mercurial.  I don't have any
opinion on which are better, just that the world at large is far more
familiar with git than mercurial, there's more tools for that ecosystem
(GitKraken is supremely excellent), and so forth.

It's not necessary to use Github to use Git, fortunately.  There are other
Git servers that provide similar capabilities to Github.  At home I use
Gogs for a few personal repositories.  I've used Gitlab in the past -- that
one has the advantage of a built-in continuous integration system.  Both
Gogs and Gitlab can be installed on your hardware.

Linus hosting it's kernel repo on github. Microsoft now hosting .net
> opensource on github either, python move from mercurial to github .
> PHP move from svn to github, Ruby on github, Swift move to github,
> Golang move to github.
> Rust lang on github, Scala on github, haskell GHC on github, Clojure
> on github, kotlin on github.
> So why you afraid move to github?



Github, github, github, github....   Can you say "Single Point of Failure"?


What's wrong with this picture is if everyone adopts Github what happens
when Github flames out in a big horrible way?

It'd be like the problem we collectively face with monocultures in the food
supply.  If there's only one kind of corn being grown, and a nasty virus
starts infesting that one variety of corn, won't that wipe out our food
supply and we'll all starve?

But ... discussing Git is outside the scope of this.  I think when Kelly
O'Hair says the conversion would be a major headache, that you should pay
attention.

Getting to more important things ... what about JCP and JSR's?

Previously the major release cycles were designed to coincide with JSR's
being finished.

I take it the idea that a JSR will land in whatever release it coincides
with rather than rigidly holding up a release until the JSR is finished.
And that the reason for more granular releases is to decrease the time
between a JSR finishing and it landing in an official release.  Is that
about right?


+ David Herron
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Brian Goetz-2

On 9/11/2017 6:27 PM, David Herron wrote:

> Getting to more important things ... what about JCP and JSR's?
>
> Previously the major release cycles were designed to coincide with JSR's
> being finished.
>
> I take it the idea that a JSR will land in whatever release it coincides
> with rather than rigidly holding up a release until the JSR is finished.
> And that the reason for more granular releases is to decrease the time
> between a JSR finishing and it landing in an official release.  Is that
> about right?

Platform JSR for 18.3 posted yesterday:
     https://jcp.org/en/jsr/detail?id=383

Now in review, to be followed by ballot, in accordance with JCP process,
as usual.

Component JSRs will come in as they always have; through the appropriate
platform (umbrella) JSRs.

Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Andrew Haley
On 13/09/17 15:25, Brian Goetz wrote:

>
> Platform JSR for 18.3 posted yesterday:
>      https://jcp.org/en/jsr/detail?id=383
>
> Now in review, to be followed by ballot, in accordance with JCP process,
> as usual.
>
> Component JSRs will come in as they always have; through the appropriate
> platform (umbrella) JSRs.

But why the blinking flip is it called 18.3?  I've looked in a few emails but I
get so many, I may have missed the explanation.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

mark.reinhold
2017/9/13 9:55:34 -0700, [hidden email]:

> On 13/09/17 15:25, Brian Goetz wrote:
>> Platform JSR for 18.3 posted yesterday:
>>
>>     https://jcp.org/en/jsr/detail?id=383
>>
>> Now in review, to be followed by ballot, in accordance with JCP process,
>> as usual.
>>
>> Component JSRs will come in as they always have; through the appropriate
>> platform (umbrella) JSRs.
>
> But why the blinking flip is it called 18.3?  I've looked in a few emails but I
> get so many, I may have missed the explanation.

From my blog entry (https://mreinhold.org/blog/forward-faster):

  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".

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Andrew Haley
On 13/09/17 17:59, [hidden email] wrote:

> 2017/9/13 9:55:34 -0700, [hidden email]:
> From my blog entry (https://mreinhold.org/blog/forward-faster):
>
>   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. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Peter Lawrey-3
In reply to this post by mark.reinhold
This reminds me of the Ubuntu version numbers which I don't mind at all.

https://wiki.ubuntu.com/Releases

Note: the $MONTH is always 2 digits which has a nice symmetry as "yy'.'MM".
If we avoid releasing after September each year, one digit should be fine.

-- Peter.


On 13 September 2017 at 17:59, <[hidden email]> wrote:

> 2017/9/13 9:55:34 -0700, [hidden email]:
> > On 13/09/17 15:25, Brian Goetz wrote:
> >> Platform JSR for 18.3 posted yesterday:
> >>
> >>     https://jcp.org/en/jsr/detail?id=383
> >>
> >> Now in review, to be followed by ballot, in accordance with JCP process,
> >> as usual.
> >>
> >> Component JSRs will come in as they always have; through the appropriate
> >> platform (umbrella) JSRs.
> >
> > But why the blinking flip is it called 18.3?  I've looked in a few
> emails but I
> > get so many, I may have missed the explanation.
>
> From my blog entry (https://mreinhold.org/blog/forward-faster):
>
>   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".
>
> - Mark
>