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.
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/ Tim On Tue, Oct 11, 2011 at 3:01 PM, Paul Spencer <pagam...@gmail.com> wrote: > I am +1 for rethinking how we use branches. I think the branch model works > well for MapServer where they tend to release multiple times from the same > branch (http://trac.osgeo.org/mapserver/browser/branches ... 11 branches but > that goes back a long time). I think we should have branches grouping > API-compatible versions, i.e. a branch for version 1, one for version 2, and > one for version 3 and just tag releases within each branch. > As Andreas suggests, its always possible to go back and branch from a tag if > it is deemed really necessary to release a bugfix version of a previous > release. > Cheers > Paul > > On 2011-10-11, at 3:29 PM, Tim Schaub wrote: > > Ok, I shouldn't have brought up the `git branch -avv` bit. > > How about this: > > Linux, 1 branch > https://github.com/torvalds/linux/branches > > jQuery, 1 branch > https://github.com/jquery/jquery/branches > > git, 5 branches (feature related) > https://github.com/git/git/branches > > OpenLayers, 16 branches (only one is feature related) > https://github.com/openlayers/openlayers/branches > > Are we special, or are we misusing branches? > > Tim > > On Tue, Oct 11, 2011 at 11:19 AM, Eric Lemoine > <eric.lemo...@camptocamp.com> wrote: > > > On Tuesday, October 11, 2011, Tim Schaub <tsch...@opengeo.org> wrote: > > I don't see real value in keeping around all of the old release > > branches. If we were continuing to do releases in the 2.4.x series, > > for example, the 2.4 branch would have a clear purpose. We can check > > out release tags to run tests or do other work with a specific > > release. Can anyone point to a clear purpose for keeping around the > > old release branches? > > In case we do want to keep open the possibility of creating a patch > > release from an old minor release, we could keep around two release > > branches. My motivation for cleaning up old release branches is that > > I like to run `git branch -avv` and the output is a bit ridiculous if > > you have a couple remotes. > > I'm +1 on getting rid of old release branches (keeping around the > > latest two if others think that is a good idea). > > If there is a compelling reason to keep around older branches, I'm > > open to changing my opinion. > > This makes me wonder how maintainers use Git/github. I know a lot create > > "release tags", but do they also create "release branches"? And if they > > don't, how do they handle the case where they want to go back and do a > > bugfix release? > > If feels a bit weird to me to delete branches because the output of 'git > > remote -avv' is ugly. But if "release branches" are unnecessary (and > > possibly silly) when using Git and github I'm +1 on deleting them entirely, > > and dedicating branches to shared experimental work or something. > > -- > > Eric Lemoine > > Camptocamp France SAS > > Savoie Technolac, BP 352 > > 73377 Le Bourget du Lac, Cedex > > Tel : 00 33 4 79 44 44 96 > > Mail : eric.lemo...@camptocamp.com > > http://www.camptocamp.com > > > > > > -- > Tim Schaub > OpenGeo http://opengeo.org/ > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > d...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/openlayers-dev > > -- Tim Schaub OpenGeo http://opengeo.org/ Expert service straight from the developers. _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
