Hello, * Peter O'Gorman wrote on Mon, Aug 09, 2010 at 05:38:44PM CEST: > 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. > > 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). > > I don't really care what the version number is - as long as it's > greater than the previous one :-)
I agree with Peter on all accounts. Our testsuite has been getting better, so more issues should be exposed (given testing on suitably many different systems and setups); also, the w32 stuff has cooked long enough now; no, let me clarify: it has been cooking far too long already (blame me if you like). I don't think having more than one release branch will increase adoption rates at all. In fact, I really prefer having *one* version only, because if anything then we are already understaffed for one branch. Feature branches are cool, but should be merged in a timeframe measured in (low-digit) weeks. At least, that should be the goal. (Yes, I can at least try!) I also don't think that cherry-picking already published patches is a grand idea, now that I've come to like branching and merging a lot in Automake. ;-) But I'm fine with ignoring that for the sake of this discussion. I do think however that it's time that our testing efforts become a bit more coordinated, to make regression tracking easier and more apparent. Will reply to this post with more details. * Gary V. Vaughan wrote on Mon, Aug 09, 2010 at 06:52:19PM CEST: > 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. Do you really want to reopen this can? IMVHO 2.x took so long because it was destabilized *too* *much*. > 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 :-) Except that the new branch is completely untested, the interaction of cherry-picked patches with non-ones is unknown ... Cheers, Ralf