Proposal to revise forest graph and integration practices for JDK 9

mark.reinhold at mark.reinhold at
Mon Dec 2 11:50:35 PST 2013

2013/12/1 13:04 -0800, joe.darcy at
> On 11/25/2013 5:40 AM, Dalibor Topic wrote:
>>> (Conceptually, in this model a separate master forest is not
>>> strictly needed since the known-good states could be indicated using
>>> a mechanism like Hg tags. However, while adjusting to the new model
>>> and to allow for fixes directly to master in exceptional
>>> circumstances, I'm proposing a physically separate master forest be
>>> retained. The distinct URL of master will also clearly indicate
>>> known-good states of the source code.)
>> One of the not very useful things we did for 7u was to keep a
>> separate master forest.
>> Considering the real benefits of a master forest [1], and the real
>> drawbacks when it's being used with a rapidly changing tree
>> underneath [2], I'd suggest you drop the master forest for JDK 9.
> Thanks for the feedback on that point of the proposal; I'm still 
> uncomfortable with collapsing master and dev before we put the model 
> into practice.

Can you say more about your discomfort?  Eliminating the master/dev
distinction is another good simplification, I think, and if we're
going to shake things up anyway then now is a good time to do it.

Is your concern mainly that consumers of the master forest will have
to change their habits, and always look for the current build tag?

One way to make that easier would be to define another tag, say
jdk9-current, that also tags the latest jdk9-bXXX changesets.

- Mark

More information about the jdk9-dev mailing list