Managing parallel change in JDK 8 and JDK 9

[mark.reinhold at oracle.com]

The rate of change in JDK 8 is ramping down, and the JDK 9 forests will
be open soon.  Until JDK 8 ships, how shall we manage changes that need
to go into both releases?

The general rule, of course, is that changes should go into the current
development release first, where they can "soak" through a few testing
cycles before they're backported to earlier releases.

This rule doesn't make a lot of sense during the endgame of a feature
release, since the release in preparation (JDK 8, in this case) will be
much more thoroughly tested during this period than its newly-started
successor (JDK 9).  It would also slow down work on the endgame release,
since all changes would have to go through its successor first.

In past releases, up to and including JDK 7, we didn't have a set policy
for managing this kind of parallel change.  A developer would typically
push a change to the release in which it was first required.  Someone,
usually from Sun/Oracle's Release Engineering team, would perform
semi-automatic merges from the endgame release to the successor release
until such time as those merges became impractical due to divergence.
At that point developers would be asked to push changes required in the
endgame release into both releases, when appropriate, and bug-database
queries would be used to help ensure that every change wound up in the
appropriate release(s).

This approach has never scaled very well.  It requires every one of the
hundreds of developers contributing to the endgame release to monitor
whether semi-automatic merges are still being done, and then to change
their integration workflows as soon as those merges stop.  It differs
from the established approach of the JDK 8 and JDK 7 Update releases,
in which there are never semi-automatic merges.  Finally, it's a burden
on those doing the merges, who often don't have the expertise needed to
judge the correctness of a merge and thus wind up having to get help
from the original developer.

To simplify the release-endgame process, I hereby make the following
proposal:

  The JDK 9 development forests will be initialized from a specific
  build of JDK 8.  After that build, merges between the two code lines
  will not be permitted.  A developer who pushes a change into JDK 8
  must also apply that change independently to JDK 9, if that change
  is applicable to JDK 9.

By "apply independently" I mean "cherry pick"; i.e., export the patch
for the JDK 8 changeset, apply the patch to a JDK 9 working forest,
adjust the result as needed, build and test, and then commit a new
changeset to JDK 9 with the same bug number and other log information.

This change will, I hope, make things clearer for everyone.  The only
downside I can see is that it won't be possible to build JDK 8 GA from
a JDK 9 forest since the latter will fork from JDK 8 prior to GA.  It's
somewhat convenient -- and kind of cool -- to be able to do that, but I
think it has more aesthetic than technical value.  You can't build a JDK
7 Update release from a JDK 8 forest; this situation is no different.

(There might be a way to merge JDK 8 GA into JDK 9, for the historical
 record, using named-branch trickery and some jcheck refinements, but
 that's something we can always do after the fact.)

Comments?

- Mark