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. > > 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. Matt > > There are probably better models. Suggestions? > _______________________________________________ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
