Re: ok, new libtool for cygwin updates

[Gary V . Vaughan]

On Friday 30 March 2001  2:23 am, Alexandre Oliva wrote:
> On Mar 29, 2001, "Gary V. Vaughan" <address@hidden> wrote:
> > Which reminds me... once this patch is in and working, I'd like to
> > release libtool-1.3d (probably over the weekend) and declare a feature
> > freeze in HEAD so that we can shake the bugs out and release 1.4 a week
> > or two later.
> >
> > Is that okay with everyone?
>
> Not really.  We really must fix the bug that causes us to remove
> duplicate libraries before releasing 1.4.

Huh?  Seems like I'm missing something here.  What is this bug exactly?

If it is not a showstopper (i.e. makes libtool not work in the common case),
then releasing 1.3d seems like a good way to have people look at it and help 
with patches...  Of course I expect to wait until all known bugs are fixed 
before releasing 1.4.  After that I'm inclined to experiment with more 
regular alpha releases -- say one a month except where we discover 
showstoppers in CVS which would need to be fixed before making an alpha 
release.  If we have a good feeling about a couple of consecutive alphas and 
there are no known bugs, we can make an impromptu point release without the 
undue delays that we have had by piling more and more features in to 1.4.

Infact, I'm keen to remove the multiple branches philosophy which has helped 
to slow development so much in the last year or two, but rather to have a 
regular alpha release process, so that before making major changes (such as 
Bruce's AutoGen patch) we dub the next scheduled alpha as a feature freeze, 
concentrate on only bug fixing for the next cycle, and then make a full point 
release with maintenance branch so that the big change can develop in the 
trunk, and have everyone look at it.  The situation we have at the moment 
with half of our users taking releases from MLB and half from HEAD means that 
finding bugs takes twice as long.  What do you think?

> > Then we can finally get on with the messy business of merging
> > MLB... any volunteers? =)O|
>
> Well...  Moving MLB onto the trunk is trivial, so I could do that, for
> sure.  However, merging it such that ltconfig.in is folded into
> libtool.m4 in the process isn't.

I'd be happy to redo the ltconfig elimination in MLB after 1.4 and before the 
merge.  I must admit that I don't currently know how to combine this with the 
tags feature... infact, since I don't use MLB myself, I don't even know how 
tags work.  Maybe we could agree to break MLB for a while so that I can 
eliminate ltconfig, but leave someone more intimate with tags to get them 
working again afterwards?  After that, the merge should become much easier.  
Comments?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc