<br><br>On Tuesday, October 11, 2011, Tim Schaub <<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>> wrote:<br>> I don't see real value in keeping around all of the old release<br>> branches. If we were continuing to do releases in the 2.4.x series,<br>
> for example, the 2.4 branch would have a clear purpose. We can check<br>> out release tags to run tests or do other work with a specific<br>> release. Can anyone point to a clear purpose for keeping around the<br>
> old release branches?<br>><br>> In case we do want to keep open the possibility of creating a patch<br>> release from an old minor release, we could keep around two release<br>> branches. My motivation for cleaning up old release branches is that<br>
> I like to run `git branch -avv` and the output is a bit ridiculous if<br>> you have a couple remotes.<br>><br>> I'm +1 on getting rid of old release branches (keeping around the<br>> latest two if others think that is a good idea).<br>
><br>> If there is a compelling reason to keep around older branches, I'm<br>> open to changing my opinion.<br><br>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?<br>
<br>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.<br>
<br>-- <br>Eric Lemoine<br><br>Camptocamp France SAS<br>Savoie Technolac, BP 352<br>73377 Le Bourget du Lac, Cedex<br><br>Tel : 00 33 4 79 44 44 96<br>Mail : <a href="mailto:eric.lemoine@camptocamp.com">eric.lemoine@camptocamp.com</a><br>
<a href="http://www.camptocamp.com">http://www.camptocamp.com</a><br><br>