libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.5 release


From: Ralf Wildenhues
Subject: Re: 1.5 release
Date: Sat, 23 Apr 2005 10:38:05 +0200
User-agent: Mutt/1.5.6+20040907i

Hi Gary, others,

* Gary V. Vaughan wrote on Sat, Apr 23, 2005 at 09:40:05AM CEST:
> Ralf Wildenhues wrote:
> > Another couple of questions that turned up for me and are not
> > dealt with in HACKING (resp. README-alpha):
> 
> Thanks for catching these!  We should capture the concensus in HACKING...

Yep.

> > Do I have to increase the serial on libtool.m4 before releasing?
> > Or after releasing?
> 
> No, because people might like to use CVS versions (once their favourite
> patches have been incorporated for example), and we want to support them
> too.  The serial on each M4 file should be incremented each time the
> interface changes, independently of release schedules.

OK.  No change necessary for branch-1-5 then.

> For M4 files on branches, we ought to be using cvs like `.' delimited
> #serial numbers, otherwise a busy branch might end up with a serial
> number that overtakes the trunk :-o  Only version.m4 does this right at
> the moment.

Good thing I don't have to think about this ATM.  :)

> > Also the library version of libltdl in libltdl/Makefile.am, right?
> > (libltdl hasn't changed yet from the previous release, but I will
> > try to incorporate the memleak patch).
> 
> Same answer -- in order to support people who use CVS versions of
> libtool, the libltdl library versions should be incremented at the time
> we change the interface.

OK.

> Supporting branched revisions is more difficult here, because we need to
> be sure that a branch release doesn't 'catch up' with the trunk and
> start using the same interface numbers that were once used on an older
> trunk revision.  I think the best way to prevent these problems is to
> incorporate the branch number in the libltdl soname.

Ouch.  Let's avoid doing anything like that if we can.

> I think -release
> is ugly, but it is all we have right now.  Releases from branch-1-5
> haven't used it thus far, and 1.5.16 doesn't break binary compatibility
> with 1.5.14, so for branch-1-5 it is too late already I think.

If you ask me, I don't want to see _any_ changes on a stable branch
except incrementing REVISION, unless absolutely necessary.

> For branch-2-0, I think we should start using `-release 2.0' right away.
> Opinions?

IMVHO no.  We already have a higher CURRENT on branch-2-0 than on HEAD.
We need just release 2.2 with a higher CURRENT than 2.0 and be done
with it.

All I wanted to do is increase REVISION, on branch-1-5.

Thanks for answering so quickly.  I'll post my proposed README as soon
as I have it done (should be today).

Regards,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]