Accelerating the JDK release cadence

[mark.reinhold at oracle.com]

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:

  https://mreinhold.org/blog/forward-faster

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"
Projects:

  - 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 [1] 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 [2], enter Rampdown Phase 2
    [3] a month later, and then enter the Release Candidate phase [4] 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 [5] 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 [6], 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" [7] such as Java Flight Recorder and Mission
    Control [8], under a click-through binary-code license [9].  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


[1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[2] http://openjdk.java.net/projects/jdk9/rdp-1
[3] http://openjdk.java.net/projects/jdk9/rdp-2
[4] http://openjdk.java.net/projects/jdk9/rc
[5] http://openjdk.java.net/jeps/0
[6] http://openjdk.java.net/legal/gplv2+ce.html
[7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
[9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html