[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Next Libtool Point Release Pending
From: |
Ralf Wildenhues |
Subject: |
Re: Next Libtool Point Release Pending |
Date: |
Mon, 9 Aug 2010 20:42:24 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
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
- Re: [RFT PATCH v4 0/8] Sysroot series, (continued)
- Re: [RFT PATCH v4 0/8] Sysroot series, Charles Wilson, 2010/08/08
- Next Libtool Point Release Pending [Was Re: [RFT PATCH v4 0/8] Sysroot series], Gary V. Vaughan, 2010/08/06
- Re: Next Libtool Point Release Pending, Ralf Wildenhues, 2010/08/06
- Re: Next Libtool Point Release Pending, Gary V. Vaughan, 2010/08/06
- Re: Next Libtool Point Release Pending, Bob Friesenhahn, 2010/08/06
- Re: Next Libtool Point Release Pending, Gary V. Vaughan, 2010/08/06
- Re: Next Libtool Point Release Pending, Ralf Wildenhues, 2010/08/06
- Re: Next Libtool Point Release Pending, Gary V . Vaughan, 2010/08/09
- Re: Next Libtool Point Release Pending, Peter O'Gorman, 2010/08/09
- Re: Next Libtool Point Release Pending, Gary V. Vaughan, 2010/08/09
- Re: Next Libtool Point Release Pending,
Ralf Wildenhues <=
- autobuild logs for Libtool (was: Next Libtool Point Release Pending), Ralf Wildenhues, 2010/08/09
- Re: autobuild logs for Libtool, Ralf Wildenhues, 2010/08/22
- proposed autobuild_mode naming scheme (was: autobuild logs for Libtool), Ralf Wildenhues, 2010/08/22
- Re: proposed autobuild_mode naming scheme (was: autobuild logs for Libtool), Gary V. Vaughan, 2010/08/22
- Re: proposed autobuild_mode naming scheme (was: autobuild logs for Libtool), Gary V. Vaughan, 2010/08/22
- Re: proposed autobuild_mode naming scheme, Ralf Wildenhues, 2010/08/29
- Re: autobuild logs for Libtool, Gary V. Vaughan, 2010/08/22
- Re: autobuild logs for Libtool, Ralf Wildenhues, 2010/08/23
- Re: Next Libtool Point Release Pending, Bob Friesenhahn, 2010/08/09
- [PATCH] Autotest 2.62 bug?, Gary V. Vaughan, 2010/08/09