Managing parallel change in JDK 8 and JDK 9

[Joe Darcy]

Sounds reasonable to me.

-Joe

On 12/02/2013 03:36 PM, mark.reinhold at oracle.com wrote:
> 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