[OpenLayers-Dev] MOTION: delete old branches

[Paul Spencer]

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.lemoine at camptocamp.com> wrote:
>> 
>> 
>> On Tuesday, October 11, 2011, Tim Schaub <tschaub at 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.lemoine at camptocamp.com
>> http://www.camptocamp.com
>> 
>> 
> 
> 
> 
> -- 
> Tim Schaub
> OpenGeo http://opengeo.org/
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20111011/0baa40b0/attachment-0001.html