Accelerating the JDK release cadence

Wed Sep 6 17:07:31 UTC 2017

On Wed, Sep 6, 2017 at 4:49 PM,  <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.)
>

Hi Mark,

this is all very interesting and leaves a lot romm for discussions!

If I understand everything correctly, it really reminds me of a
proposal I made back in 2013 :) when we discussed the structure of the
then new jdk 9 repos [1]:

"why don't we create something like http://hg.openjdk.java.net/dev with
master, dev, client and hotspot forest beneath it. These forests could live
"forever". Any time a new release is ready, we would then clone jdk9,
jdk10, etc from dev/master. Wouldn't that be a more natural setup?"

So could you please be a little more specific about the vision you
have for the repositories of the new "JDK Release Project"?

What does "the main development line will always be open but fixes,
enhancements, and features will be merged only when they're nearly
finished" really means?

1. Merged from where? From which other code line or repository?

2. Do we have other kind of changes than "fixes, enhancements, and features" ?

3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least
all fixes and enhancements (i.e. 'the daily development stuff') go
into one of these repos. In the future, lets say we'll have something
like jdk/master, jdk/hs and jdk/client. Will all fixes and
enhancements be considered "nearly finished" by default? From my point
of view, everything else wouldn't make sense for our "daily work". I
understand that bigger "features" (i.e. Jigsaw, Value Types, etc.)
would have to be developed in their own, separate repositories until
"nearly ready" and only then merged into let's say jdk/master. Is it
this what you propose?

4. Having more features being developed in their own repositories
(until they are "nearly ready") raises the question, how changes for
such features will be reviewed? Currently we only have own repos for
quite big features like a new port, Jigsaw or Value Types to name some
examples. These "big" features have always been sponsored by OpenJDK
groups with their own, special review rules and later, when they have
been integrated into the main development repos they had to be
reviewed once again under the jdk8/jdk9/hotspot review rules. If we
will have much more features being developed in parallel to the main
development line, this approach would impose a significant overhead.
What do you think?

5. What do you mean by "The main line will be Feature Complete [1] at
all times". How can a development line be "feature complete"?
Features and JEPs will always be targeted to a specific release so
from my understanding only a release-branch can be "feature complete".
We can not know beforehand what will be in the next release which will
be forked from the development line (and this not only depends on the
OpenJDK, but also on the JCP!).

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

a. Targeting for a release X now means a JEP will have to be
integrated into the main development line not later than three months
before the GA date of X (i.e. before the release-stabilization branch
will be forked). That means there's always a 6-month window (between
two forks) for bringing new features into the main line right? And
during this six month, we can only integrate features into the main
line which are targeted for next release, right?

b. In other words: every feature which is integrated into the main
line in the six month period between the forks of two releases X and Y
will be targeted for Y. But again, we can't now all the features which
will go into Y after we've forked X (and it would contradict the
'train-model' if we would know). So how could the main line be feature
complete at all times?

c. For some features, such a model may be OK. But consider a "feature"
like G1. It was in hotspot for years, before it became officially
supported (i.e. "feature complete"). I don't think we can use such a
strong model of "Feature Completeness" for such kind of projects and
insist on the fact that the main development line always has to be
"feature complete". It would also be hard to split such features into
smaller parts which can still be considered features. Any thoughts on
this?

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000115.html

> 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