[Swan-dev] a different git branching model for Libreswan

[Antony Antony]

On Wed, Oct 29, 2014 at 02:09:43PM -0400, Matt Rogers wrote:
> On 10/29, D. Hugh Redelmeier wrote:
> > My suggested solution: release/freeze branches
> > ==============================================
> > 
> > We should never freeze master.
> > 
> > When we want a freeze for a release, create a release branch.
> > 
> > Work continues on master.
> > 
> > If something should be in the release (eg. a bug fix), it should be
> > created in master but cherry-picked into the release branch.
> > 
> > If a kludge is needed in the release branch, it can be done there
> > without messing up master.
> > 
> > There can still be feature branches, but they should branch from
> > master and be merged into it.
> > 
> > 
> > Alternative solutions
> > =====================
> > 
> > This is not a new problem.  Many projects have created models that
> > address it.  We could adopt them.
> > 
> > <http://nvie.com/posts/a-successful-git-branching-model/>
> > In this one, master is sacred and seems to only include final
> > releases.

I  have a slight preference for this model, however, the first looks good too. 
This way tags are all on master. 

As a release get closer, in this model we may have 3 active more branches?  
Also another advantage is we can do daily test runs on 3 branches.

> > 
> > There is a branch for each release.  It branches from "develop".  Only
> > bug fixes are added.  When ready, it gets merged into master.
> > 
> > "develop" is roughly what I proposed for "master".
> > 
> > This would be fine as far as I'm concerned.  I prefer master to be
> > where development life is lived in an open-source project.

> 
> I think having a development branch (be it master or otherwise) seperate from a
> release branch makes sense. 
> 
> Whatever we decide it would be helpful to have a wiki page with the git commands
> to use for our workflow for development/master/feature branches so we are all
> using the same methods.

+1 

-antony