Accelerating the JDK release cadence

[mark.reinhold at oracle.com]

2017/9/6 8:31:47 -0700, Andrew Hughes <gnu.andrew at redhat.com>:
> On 6 September 2017 at 15:49,  mark.reinhold at oracle.com wrote:
>> ...
>> 
>> 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?

Yes, the main-line stabilization branches will 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.

The quarterly update branches aren't public during stabilization
precisely because they contain security fixes, which can't be revealed
until the end.  One of the goals of the Vulnerability Group is to make
those fixes available earlier to maintainers (such as yourself) who need
them.

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

In what ways are Mercurial branches inadequate for this purpose?

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

Yes.

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

Well, they're already open-source, so there's nothing to do in that
sense.  The new OpenJDK builds are intended mainly for server-side/cloud
use so they won't include FX, at least to start.

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

They are a thing of the past -- the feature releases would go straight
from 9 to 18.3.

>                                                        How does update
> versioning fit in with that?

Good question!

The obvious approach is to label the 18.3 updates as 18.3.1, 18.3.2,
and so forth.  The problem with that is that if we need to create an
emergency release to address an urgent security issue then we'd have
to renumber the update line currently in development, which is painful.
An alternative is to label them 18.3.$AGE, where $AGE is the number of
months since the 18.3 GA release.  That'd give us 18.3.1, 18.3.4, etc.,
with spare numbers in between for emergency releases, much like what
we've done for years with the JDK 7/8 updates.

(Version schemes are, in general, a huge bikeshed -- second only to
 language syntax -- so I'm sure there will be much more discussion of
 this topic.)

- Mark