[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Next Libtool Point Release Pending
From: |
Gary V. Vaughan |
Subject: |
Re: Next Libtool Point Release Pending |
Date: |
Sat, 7 Aug 2010 01:53:15 +0700 |
Hi Bob,
On 6 Aug 2010, at 22:30, Bob Friesenhahn wrote:
> On Fri, 6 Aug 2010, Gary V. Vaughan wrote:
>>>
>>> OTOH, since I hope to have more larger changes in the future, I'm not
>>> sure we really want another major number bump already.
>>
>> That's only a minor bump, according to major.minor.micro:
>>
>> major bump => substantial rewrite
>> minor bump => new features, new code and new bugs
>> micro bump => regressions and bugs fixed
>>
>> This is the scheme I believe most people recognize, and that suggests
>> to me that 2.4.0 would be the next logical release number?
>
> You do make a good point. It is better to advance the minor number (rather
> than continually increase the micro number) if significant new features have
> been added. However, the objectives should be met (e.g. really able to build
> adequately with MSVC) before we bump to 2.4. This should not discourage
> including 99% of the necessary updates in another 2.2 release.
Nonetheless I still think that users should have some confidence that
releases get more stable as micro increases. Rolling a ton of new
code into a micro bump violates that idea.
In this case I should either release a 2.2.12b alpha while we wait
for the new MSVC code to be "adequate" for 2.4.0, or else make a
retroactive 2.2 maintenance branch at v2.2.10 in git, and back-
merge fix changesets only from trunk to make stable 2.2.12 while
waiting for an appropriate time to roll 2.4.0 from master.
IMHO 2.4.0 from master at the end of the month (assuming no
known show-stoppers at that time) is a good and proper way to
inform users that there's some new code (minor+=2), and that
it's not at all mature (micro=0). 2.2.12, on the other hand,
misinforms users that this is a stable release with nothing
important altered (major.minor unchanged), and they really
should upgrade to pick up the last round of bug fixes (micro+=2).
Another viable compromise might be to call the next release
2.3.0?
Cheers,
--
Gary V. Vaughan (address@hidden)
- Re: [RFT PATCH v4 0/8] Sysroot series, (continued)
- Re: [RFT PATCH v4 0/8] Sysroot series, Thierry Reding, 2010/08/09
- 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 <=
- 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, 2010/08/09
- 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