Repository? -- How to keep JDK 10 up to date with changes in JDK 9 until JDK 9 GA?

[Kevin Rushforth]

This seems like a very good approach. We did this quite successfully for 
JavaFX syncing changes from 8 to 9 when JDK 9 started. It recognizes the 
reality that most bug fixing between now and JDK 9 ZBB will happen in 
the jdk9 forest. One caution is that any significant refactoring or 
restructuring of the source code in JDK 10 (e.g., the repo consolidation 
that is underway as a prototype) will cause merge challenges if such 
refactoring is done before JDK 9 ZBB.

-- Kevin


Joseph D. Darcy wrote:
> On 12/2/2016 4:21 PM, Joseph D. Darcy wrote:
>> On 12/1/2016 9:34 AM, mark.reinhold at oracle.com wrote:
>>> 2016/11/29 14:02:53 -0800, philip.race at oracle.com:
>>>> I need to register my concerns for SE client (the open part, not 
>>>> closed)
>>>> I don't think it is feasible to collapse the current lines of 
>>>> development
>>>> unless all our current testing done at PIT is able to be run for 
>>>> every push
>>>> and we are nowhere near that. Maybe even further away than we were 
>>>> before.
>>> So, are you saying that you want a separate "client" forest in JDK 10,
>>> as in past releases, at least for now?
>>
>> While continuing discussions about whether or not a separate client 
>> forest is merited, I think it would be acceptable to go forward with 
>> creating the master/dev forest and the separate forest for HotSpot, 
>> the latter named "hs".
>>
>
> While the number of lines of development discussion is wrapping up, 
> before the JDK 10 forests open I think it is worthwhile to consider 
> another question: how should the JDK 10 forests be kept up to date 
> with changes being made in JDK 9 between the time JDK 10 opens and JDK 
> 9 GA?
>
> The current schedule for JDK 9 has its GA on July 27, 2017. [1] For 
> JDK 9 builds 137 through 147, the average number of fixes per builds 
> was about 108. While the rate of bug fixes is expected to diminish as 
> the release enter rampdown, I'd still expect many hundreds of fixes to 
> be made in JDK 9 before it ships.
>
> In the shorter overlap between the opening of JDK 9 (Dec. 2013 [2]) 
> and the rampdown and GA of JDK 8 (March 2014 [3]), engineers were 
> expected to be responsible for pushing their fixes both to JDK 8 and 
> JDK 9. [4] While this approach is tractable for a relatively small 
> number of changes, about 300 in the 12 builds of JDK 8 after JDK 9 
> branched off, I don't think it would scale well for the larger number 
> of fixes expected during the overlap of JDK 9 and 10.
>
> Therefore, I think a different approach should be used this time 
> around. Rather than protracted cherry-picking, I think changes in JDK 
> 9 promoted builds should be merged into JDK 10, at least until JDK 9 ZBB.
>
> Comments?
>
> Thanks,
>
> -Joe
>
> [1] http://openjdk.java.net/projects/jdk9/
>
> [2] 
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000146.html
>
> [3] 
> http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html
>
> [4] 
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-December/003766.html, 
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000158.html