On Aug 9, 2010, at 10:38 PM, Peter O'Gorman <pe...@pogma.com> wrote: > On 08/09/2010 12:33 AM, Gary V. Vaughan wrote: >> By the reasoning I stated there, we should really have branched >> for 2.2 releases before adding any new features. So, if we >> want to release a 2.2.12, then we should make a branch at >> v2.2.10 and merge only fixes to it. > > I don't think having a stable and development branch worked well with 1.5.x > and 2.x. It added more work for us, and did not serve our users well - they > had to wait years for the development branch's features to make it into a > released libtool.
That's true, but I think that was because we tried too hard to make the 2.x branch perfect, and spent altogether too much time pumping out more and more 1.5.x releases with patches merged back from an ever diverging code base. As long as we're careful not to do any of this things, then we can avoid repeating history. > Developing new features etc. on a branch is, of course, ok, in my opinion > (having to wait several years to merge is not so good though). You make a good point. Does git offer the means to relabel the head of a branch as master? Then I can cherry-pick the bug fixes from the current master, rename it to branch-2-2, and relabel the cherry-picked branch as the new master... voilà: stable master, and feature branch for msvc :-) > I don't really care what the version number is - as long as it's greater than > the previous one :-) Then I'm still voting for 2.4.0 for a release from master :-) Cheers, -- Gary V. Vaughan (g...@vaughan.pe)
