On Wednesday, October 12, 2011, Tim Schaub <tsch...@opengeo.org> wrote: > Another way to look at this is that if we have a lot of commits in a > release branch that aren't in our master branch, we're doing something > wrong. Currently, the diff views are a bit misleading > (https://github.com/openlayers/openlayers/compare/master...2.6) - that > represents a number of commits that are in both the 2.6 branch and > master, but they only look different due to how git-svn works and/or > how we merged in svn.
That's indeed a good reason to rethink our branching model. > We have to talk about how we want to handle branching as we approach > the next release. Here's a post that I think we've passed around > before: http://nvie.com/posts/a-successful-git-branching-model/ Thanks for the link. So these guys work with two permanent branches: a development branch ("develop") and a production branch ("master"). And they also work with temporary branches: release branches for preparing x.y releases, and hotfix branches for preparing x.y.z releases. It seems to me that we could start with a simple model: the "master" branch for development (as we do today), and temporary release branches for preparing releases. Temporary release branches are created from "master" for x.y releases, or from a release tags for x.y.z releases. <http://stackoverflow.com/questions/6939940/first-major-release-from-git> also includes useful information. +1 from me for deleting the current branches. Cheers, _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
