<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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 (<a href="http://trac.osgeo.org/mapserver/browser/branches">http://trac.osgeo.org/mapserver/browser/branches</a> ... 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. <div><br></div><div>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.</div><div><br></div><div>Cheers</div><div><br></div><div>Paul</div><div><br></div><div><br><div><div>On 2011-10-11, at 3:29 PM, Tim Schaub wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Ok, I shouldn't have brought up the `git branch -avv` bit.<br><br>How about this:<br><br>Linux, 1 branch<br><a href="https://github.com/torvalds/linux/branches">https://github.com/torvalds/linux/branches</a><br><br>jQuery, 1 branch<br><a href="https://github.com/jquery/jquery/branches">https://github.com/jquery/jquery/branches</a><br><br>git, 5 branches (feature related)<br><a href="https://github.com/git/git/branches">https://github.com/git/git/branches</a><br><br>OpenLayers, 16 branches (only one is feature related)<br><a href="https://github.com/openlayers/openlayers/branches">https://github.com/openlayers/openlayers/branches</a><br><br>Are we special, or are we misusing branches?<br><br>Tim<br><br>On Tue, Oct 11, 2011 at 11:19 AM, Eric Lemoine<br><<a href="mailto:eric.lemoine@camptocamp.com">eric.lemoine@camptocamp.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Tuesday, October 11, 2011, Tim Schaub <<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">I don't see real value in keeping around all of the old release<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">branches. If we were continuing to do releases in the 2.4.x series,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for example, the 2.4 branch would have a clear purpose. We can check<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">out release tags to run tests or do other work with a specific<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">release. Can anyone point to a clear purpose for keeping around the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">old release branches?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In case we do want to keep open the possibility of creating a patch<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">release from an old minor release, we could keep around two release<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">branches. My motivation for cleaning up old release branches is that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I like to run `git branch -avv` and the output is a bit ridiculous if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">you have a couple remotes.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I'm +1 on getting rid of old release branches (keeping around the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">latest two if others think that is a good idea).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If there is a compelling reason to keep around older branches, I'm<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">open to changing my opinion.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This makes me wonder how maintainers use Git/github. I know a lot create<br></blockquote><blockquote type="cite">"release tags", but do they also create "release branches"? And if they<br></blockquote><blockquote type="cite">don't, how do they handle the case where they want to go back and do a<br></blockquote><blockquote type="cite">bugfix release?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If feels a bit weird to me to delete branches because the output of 'git<br></blockquote><blockquote type="cite">remote -avv' is ugly. But if "release branches" are unnecessary (and<br></blockquote><blockquote type="cite">possibly silly) when using Git and github I'm +1 on deleting them entirely,<br></blockquote><blockquote type="cite">and dedicating branches to shared experimental work or something.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">Eric Lemoine<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Camptocamp France SAS<br></blockquote><blockquote type="cite">Savoie Technolac, BP 352<br></blockquote><blockquote type="cite">73377 Le Bourget du Lac, Cedex<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Tel : 00 33 4 79 44 44 96<br></blockquote><blockquote type="cite">Mail : <a href="mailto:eric.lemoine@camptocamp.com">eric.lemoine@camptocamp.com</a><br></blockquote><blockquote type="cite"><a href="http://www.camptocamp.com">http://www.camptocamp.com</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>Tim Schaub<br>OpenGeo <a href="http://opengeo.org/">http://opengeo.org/</a><br>Expert service straight from the developers.<br>_______________________________________________<br>Dev mailing list<br><a href="mailto:Dev@lists.osgeo.org">Dev@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/openlayers-dev">http://lists.osgeo.org/mailman/listinfo/openlayers-dev</a><br></div></blockquote></div><br></div></body></html>