Accelerating the JDK release cadence

[Andrew Hughes]

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:
>
>   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.)

Will these branches (whatever form they take) now be public? With the current
8u project, the stage between a release being forked for stabilization and then
released is currently non-public. There are obvious issues there with security
fixes, but currently we can only pick up a release at least a month
behind because
we don't have access to it in a finished form until release.

For example, we'll not have access to 8u152 in its final form until
late October,
so I can't see us being able to release builds based on it until November at the
earliest.

Incidentally, my vote would be for separate repositories to avoid confusion.
My experience of Mercurial branches is they don't work in the same way as
in other distributed version control systems, such as git in particular.

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

So I imagine the use case will be similar to now, where a fix is pushed to the
main line first, and then a backport requested in the updates project? I can
see that being most relevant for the long-term support release, especially
when it gets into its second and third years.

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

This is great news!

What about open source features that are currently bundled with the Oracle
builds, such as JavaFX?

> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?

>From your blog:

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

How does this interact with the idea of Java 9, 10, etc? Will those be a
thing of the past or will we see versions like 9.18.3? How does update
versioning fit in with that?

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

Certainly a lot of food for thought.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222