Sounds reasonable to me. -Joe
On 12/02/2013 03:36 PM, mark.reinh...@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
