Accelerating the JDK release cadence

Wed Sep 6 15:12:46 UTC 2017

I'm glad to see this happen. In general it seems fine (although I'm
still looking forward to OpenJDK on git ;-)

My only comment is the proposed version numbers. IMO, year-based
versions don't work well, who wants Java to be like Windows 95?

I'd suggest a simple incrementing number - like Chrome - is quite
sufficient for the problem - 10, 11, 12, 13

Stephen

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