[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