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
_______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
