Re: release policy [was more bugs in branch-2-0/HEAD]

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:35:32PM CEST:
>>Charles Wilson wrote:
>>
>>>Huh?  Right now (on cygwin) the shared library built by 1.5.x libtool is
>>>"cygltdl-3.dll"  (e.g. current - age == 3).
>>>
>>>Somebody somewhere already bumped the c:r:a numbers in HEAD because
>>>libtool-HEAD on cygwin creates cygltdl-6.dll.  So which previous
>>>**releases** of libltdl are you trying to distinguish from, here, Ralf?
>>
>>My thoughts too at first, but checking 1.9f current was already 6, and
>>this is an incompatible change with 1.9f.
> 
> 
> First this, and besides I was referring to this policy in HACKING:
> | * Double check that libltdl version number updates weren't forgotten
> |   since last release (they should be updated in CVS along with commits
> |   that require it so that users can work with CVS snapshots).
> 
> which, I believe, stems from the fact that somebody needed post-1.5
> stuff but with 2.0 not in sight.

Hmmm... good catch, I hadn't spotted that, but...

> So while we are at it, it might be a good idea to remove the
> parenthesized part..

Yes, I agree.  It seems wrong to churn the numbers so fast.  I don't
think it is too much to expect people who track CVS to have to deal
with regressions and experimental apis that later get fixed to restore
backwards compatibility.  Can you fix that please?

>>>libtool's own documentation recommends to its users that they manage
>>>c:r:a numbers so that they do NOT increment them until actual releases.
>>> Otherwise thrash during the development cycle over-increments them --
>>>like you're proposing now.
>>
>>It depends on whether policy is to count alpha releases or not, but it
>>seems reasonable to not trip up our alpha testers by trying to save a
>>few numbers - we have an infinite supply after all ;-)
> 
> because this is not the whole truth.  Increasing versions comes at a
> cost.  In some situations, this cost is high.
> 
> I agree with Charles that we should change this policy.  But that will
> only work if we also change our release behavior (to release more
> frequently).  And autotools interdependence requirements...

Okay.

I propose that we move from a feature driven release policy to a time
based one.  After 2.0, we should aim for a stable release (say) every
3 months, with a feature freeze in the last six weeks.  To maintain
forwards momentum, and prevent another embarrassing 2.0 like debacle,
I think that every second one of those should come from HEAD.  I think
that as long as we forward port bug fixes from the last release branch
as they are applied, we should only need to maintain 2 branches at
once.

So in the future, assuming we start the process next year, our release
schedule should look something like this (not taking into account
public holidays and slipping to the nearest weekend):

   14 February 2006:  2.0.1b
   31 March 2006:     2.0.2
   15 May 2006:       2.1b
   30 June 2006:      2.2  and 2.0.4
   15 August 2006:    2.3b
   30 September 2006: 2.4  and 2.2.2
   15 November 2006:  2.5b
   31 December 2006:  2.6 and 2.4.2

We can always choose to stick with a troublesome stable branch for
longer if it turns out to need more work to iron out any bugs and
regressions rather than ploughing on with another head release...
thoughts?

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature