[Releasing] rethinking the branching scheme

Thiago Macieira thiago.macieira at intel.com
Wed Feb 19 21:01:26 CET 2014

Em qua 19 fev 2014, às 17:21:33, Frederik Gladhorn escreveu:
> What we currently have takes time and nerves and a lot of interdependencies 
> between the modules. It is not uncommon that qtbase depends on declarative
> or the other way around. Sometimes both ways in which case the revers deps
> need to be disabled in order to get a merge through CI. That and sudden
> merge conflicts that manage to pop up in the right moment. It's not
> critical, we've dealt OK with it for a year now, but it does delay us.
> That is what I really like about the proposal - it means only forward
> merges  and real branching.

The rate of activity in stable is very low close to the dev feature freeze. If 
we locked it, I don't think many people would be inconvenienced. So:

1. lock stable
2. perform upwards merge stable→dev
3. wait for dev feature freeze and integration of all valid commits
4. fast-forward stable to the right commit in dev
5. unlock stable

Step #2 would need to be done *anyway*. The question is of when it happens. 
With the multi-branch proposal, it would probably happen after the creation of 
the new branch. And, as I said, there might be a temptation to release the 
alpha before this merge happened.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Releasing mailing list