Accelerating the JDK release cadence

[David Herron]

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