Transitioning to the new Release Process

[Johannes Pfau]

Am Thu, 10 Jan 2013 20:36:40 +0100
schrieb "Jesse Phillips" <Jessekphillips+D at gmail.com>:

>[...]
> 
> However I think that extending that to a longer period isn't bad. 
> But it does mean maintaining 3 branches (released, staging, dev). 
> If we only want the usual short prep period, staging should die 
> and we just branch into a Version branch (release branch) and tag 
> when it is released. This would not need a transition period.

Staging has also 2 other small benefits: It is a central 'beta
branch', you can check out 'staging' any time and be sure this is going
to be the next release. You'll always have all the features that are in
the next release and the only updates till the next release will be bug
fixes. This is an interesting point imho.

And then there is the benefit that you'll have a central target for bug
fix pull requests:
Without staging, bug fixes usually go into master. But when a release
branch is created, bug fixes suddenly have to go into that release
branch. Then after the release, bug fixes have to go to master again
and only regression fixes can go into the release branch.

This is kinda annoying as it does not only mean the target branch for
pull requests on github has to be changed a lot, you might also have to
rebase the bugfix on the other branch.

With staging you always target staging for bug fixes. They can be
merged at any point in time.