Managing parallel change in JDK 8 and JDK 9

[Volker Simonis]

Hi Mark,

if I understand this right, there's another downside of the approach
you propose: you can't easily downport changes from JDK9 to JDK8
update releases. This is because changes in JDK9 (i.e. our
ppc-aix-port) will have ancestor changes in JDK9 which are not in JDK8
(i.e. they are there, but they are different changes with the same
content because they have been imported and not pulled into JDK9).

So what will be the best way to downport something from JDK9 to JDK8.
The only possiblity I see is again to "cherry pick"; i.e., export the
change from JDK9 and import it into JDK8. Do you see other
possibilities?

Regards,
Volker



On Tue, Dec 3, 2013 at 12:36 AM,  <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