> >>> Of course, there's no reason not to also have a stable branch >>> updated at the same time as a numbered release. >> What would be the benefit of a third branch? > > Not a branch in the same sense, but a tag (which in SVN at least are just branches that aren't updated). So we update master every 6 months as the release branch, and just tag it each time with a version number (2.0, 2.1, etc.). Then I'll build binary packages and update the website with that. Easier to remember a version number than a git hash. ;) Names are definitely easier to remember than hashes :-) My concerns with tags are logistical ones which may well have nice solutions (and may be handle by git flow automatically even, but I haven't played with this part of it yet). (I think) we would like to actively patch the release branch when there are bugs. =If we want the branch tags to be uniquely meaningful (so there aren't multiple versions called git 2.0 floating around), then we have to make sure we update them each time we patch. This could be done via point releases, but I'm not sure we will want to go through the effort of that. The best may be to have the 2.0 tag and then something that updates the tag automatically whenever a patch is (eg by suffixing the git hash tag).