Accelerating the JDK release cadence (original) (raw)

David Herron david at davidherron.com
Mon Sep 11 22:27:32 UTC 2017

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?

More information about the discuss mailing list