Accelerating the JDK release cadence

[mark.reinhold at oracle.com]

2017/9/6 10:07:31 -0700, volker.simonis at gmail.com:
> ...
> 
> 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?

That depends upon the change.  A small fix or enhancement can originate
as a simple patch or webrev, as today.  Larger changes can be developed
over time in a separate branch in the sandbox repo.  Big features will
most likely originate and evolve for a while -- possibly years -- in
their own Project-specific repos (e.g., Jigsaw, Amber, Panama, etc.).

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

No.  Do you think an important case is missing from this high-level
categorization of types of changes?

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

No.  All changes will be subject to the same, higher bar.  Historically,
however, I suspect that many of the small changes in the past few feature
releases would have cleared that bar owing to our other long-standing
practices, such as review-before-commit.

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

I don't see significant additional overhead here.  To the extent that
separate lines of development have had their own review rules then those
rules have generally been much more lax than those for merging into the
main line.  I expect that to continue, though ultimately it's up to those
working on such separate lines, whether in a sandbox branch or a separate
Project repo, to figure out how to work together, with some rules or no
rules at all.

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

The "Feature Complete" milestone is defined as "All features have been
implemented and integrated into the master forest, together with unit
tests" [1].  If a development line is "Feature Complete at all times"
then it is, by definition, always ready to enter the first ramp-down
phase in preparation for release, i.e., it's always ready to become a
release-stabilization branch.

To put it another way, the "complete" set of features at any given time
is just the set of features in the main line at that point in time.

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

Correct.

>                  That means there's always a 6-month window (between
> two forks) for bringing new features into the main line right?

Yes.

>                                                                And
> during this six month, we can only integrate features into the main
> line which are targeted for next release, right?

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?

See above.

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

Yes.  I have yet to see a big feature that can't be divided into smaller
pieces, and it's perfectly fine for a "feature" to be something that most
users won't notice.  The important thing is that every "feature" be a
coherent and testable set of changes that's ready for release.

As an example, we merged Jigsaw into JDK 9 in several large phases, each
of which could've been a separate feature over a series of six-month
time-boxed releases.  Some of those features would have had little to no
impact on users (e.g., modularizing the JDK source code), but the end
result would've been the same.

In addition to divide-and-conquer, implementation features can be merged
in an experimental mode at first (e.g., G1, AoT) and then, over time, be
made non-experimental and even become the default, if appropriate, as
they mature.  With the incubator-module concept introduced in JDK 9 [2]
we can now take a similar approach with new APIs.  (Language and VM
changes remain tricky to do in any kind of experimental or incubator
mode, though I've recently heard some ideas that are worth further
exploration.)

- Mark


[1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[2] http://openjdk.java.net/jeps/11