Proposal to revise forest graph and integration practices for JDK 9

mark.reinhold at mark.reinhold at
Thu Dec 5 09:39:52 PST 2013

2013/12/2 16:37 -0800, joe.darcy at
> On 12/02/2013 11:50 AM, mark.reinhold at wrote:
>> 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.
> I would expect some hiccups transitioning to the new model; dev *should* 
> be stable, but a problem may be found later than desired, etc.  Having a 
> separate master forest, and the potential to make out-of-band 
> integrations to it, allows an easy remedy to such a situation by doing 
> what we do know.

We can make an out-of-band fix to a unified master/dev forest simply by
updating the jdk9-current tag:

  $ hg clone -r jdk9-current$REPO
  $ cd $REPO
  $ # ... apply fix ...
  $ hg ci -m $MESSAGE
  $ hg tag -f jdk9-current jdk9-$BUILD
  $ # ... pull and merge if needed ...
  $ hg push

The weekly integration process would work in the same way, except it
would tag every repo in the forest.

The only transition required for consumers who want the latest stable
and tested "master" code is to specify the jdk9-current tag when doing
a clone or a pull:

  $ hg tclone -r jdk9-current

(This example uses John Coomes's forthcoming trees extension [1]; it
 should be simple to modify and common/bin/
 to pull a specific tag as well.)

- Mark


More information about the jdk9-dev mailing list