[Top][All Lists]
[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
- Re: Invalid switch passed to linker on Solaris 10 with Sun One Studio 8, Ralf Wildenhues, 2005/04/08
- Re: Invalid switch passed to linker on Solaris 10 with Sun One Studio 8, Bruce Korb, 2005/04/08
- Re: Invalid switch passed to linker on Solaris 10 with Sun One Studio 8, Peter O'Gorman, 2005/04/08
- 1.5 release (was: Invalid switch passed to linker on Solaris 10 with Sun One Studio 8), Ralf Wildenhues, 2005/04/11
- Re: 1.5 release, Peter O'Gorman, 2005/04/11
- Re: 1.5 release, Ralf Wildenhues, 2005/04/23
- Re: 1.5 release, Gary V. Vaughan, 2005/04/23
- Re: 1.5 release,
Ralf Wildenhues <=
- Re: 1.5 release, Ralf Wildenhues, 2005/04/23
- Re: 1.5 release, Bob Friesenhahn, 2005/04/23
- Re: 1.5 release, Ralf Wildenhues, 2005/04/23
- Re: 1.5 release, Bob Friesenhahn, 2005/04/23
- Re: 1.5 release, Ralf Wildenhues, 2005/04/23
- Re: 1.5 release, Bob Friesenhahn, 2005/04/23
- Re: 1.5 release, Alexandre Oliva, 2005/04/23
- Re: 1.5 release, Ralf Wildenhues, 2005/04/24
- Re: 1.5 release, Alexandre Oliva, 2005/04/25
- Re: 1.5 release, Ralf Wildenhues, 2005/04/25