Accelerating the JDK release cadence
stuart.monteith at linaro.org
Mon Sep 18 15:10:35 UTC 2017
This is a welcome development. One of my wishes, working on Aarch64, would
be for all architectures to be at parity on release. With open
build-and-test infrastructure, and the more frequent releases, this looks
far more achievable. In the worst case, a well maintained architecture
would be 6 months behind. In that scenario I wonder whether different
architectures would have different ideas of long-term-support releases.
Will there ever be a JDK 9u? The update releases are normally created soon
after a major release.
On 6 September 2017 at 15:49, <mark.reinhold at oracle.com> wrote:
> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to a strict, time-based
> model with a new feature release every six months, update releases every
> quarter, and a long-term support release every three years:
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community. Comments and questions about both the
> proposal and its implementation are welcome on this list.
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases. Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1. (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
> The new JDK Project will run a bit differently than the past "JDK $N"
> - The main development line will always be open but fixes, enhancements,
> and features will be merged only when they're nearly finished. The
> main line will be Feature Complete  at all times.
> - We'll fork the main line into a release-stabilization branch three
> months before the GA date of the next feature release. That branch
> will immediately be in Rampdown Phase 1 , enter Rampdown Phase 2
>  a month later, and then enter the Release Candidate phase  a
> month after that. (Whether the branch is another repository or an
> actual Mercurial branch is a detail we can figure out later.)
> - We'll continue to use the JEP Process  for new features and other
> significant changes. The bar to target a JEP to a specific release
> will, however, be higher since the work must be Feature Complete in
> order to go in. Owners of large or risky features will be strongly
> encouraged to split such features up into smaller and safer parts, to
> integrate earlier in the release cycle, and to publish separate lines
> of early-access builds prior to integration.
> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL , to
> make it easier for developers to deploy Java applications to cloud
> environments. We'll initially publish OpenJDK builds for Linux/x64,
> followed later by builds for macOS/x64 and Windows/x64.
> - We'll continue to ship proprietary "Oracle JDK" builds, which include
> "commercial features"  such as Java Flight Recorder and Mission
> Control , under a click-through binary-code license . Oracle
> will continue to offer paid support for these builds.
> - After JDK 9 we'll open-source the commercial features in order to
> make the OpenJDK builds more attractive to developers and to reduce
> the differences between those builds and the Oracle JDK. This will
> take some time, but the ultimate goal is to make OpenJDK and Oracle
> JDK builds completely interchangeable.
> - Finally, for the long term we'll work with other OpenJDK contributors
> to establish an open build-and-test infrastructure. This will make
> it easier to publish early-access builds for features in development,
> and eventually make it possible for the OpenJDK Community itself to
> publish authoritative builds of the JDK.
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out. Comments? Questions?
> - Mark
>  http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
>  http://openjdk.java.net/projects/jdk9/rdp-1
>  http://openjdk.java.net/projects/jdk9/rdp-2
>  http://openjdk.java.net/projects/jdk9/rc
>  http://openjdk.java.net/jeps/0
>  http://openjdk.java.net/legal/gplv2+ce.html
>  http://www.oracle.com/technetwork/java/javase/terms/
>  http://www.oracle.com/technetwork/java/javaseproducts/mission-
>  http://www.oracle.com/technetwork/java/javase/terms/license/index.html
More information about the discuss