[OpenLayers-Dev] MOTION: delete old branches

[Tim Schaub]

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 <pagameba at 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.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
>
>



-- 
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.