Re: Next Libtool Point Release Pending

[Ralf Wildenhues]

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