Re: [v3] update libtool_VERSION

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 25, 2008, Benjamin Kosnik <bkoz@redhat.com> wrote:

> It will give the libstdc++ more flexibility when versioning on multiple
> active branches (4_1-branch, 4_2-branch, 4_3-branch, trunk.) At the
> slight downside of making the maintainers pay more attention to
> versioning issues on each branch for every release. (Since we will have
> to bump revision after any change on branches.)

> Alexandre, do you think it makes sense to try and create a new version
> that takes into account previous changes (ie config/abi/pre/gnu.ver
> changes), or should we just start with it now, as Andreas suggests?

Since it's not possible in general to fix retroactively the past
incompatibilities, I think it makes more sense to just start with it
now.  But I haven't thought it through.  It might be beneficial to do
so, but there's also potential for problems, so I'd be conservative
and start following the procedure now.

That said, multiple active branches are not something that can be
taken into account with libtool versioning.  Say, every GCC release
implicitly modifies code in the library, so you'd have to bump up the
REVISION, but then, you also want to reflect that a 4.3 library is
newer than any 4.1 library.  I don't see that libtool's versioning
model can fit this sort of thing.  In fact, I don't see that any
library versioning model can fit this sort of thing in (i.e., in such
a way that you can *know* which version is newer after a development
fork).

I believe bumping up both CURRENT and AGE by a certain amount in the
trunk after a branch is cut, based on the number of expected major
releases in a branch and with the assumption that the branch won't
break the ABI, would be a sufficiently conservative way to deal with
it.  But this requires commitment for older branches to not overtake,
ABI-wise, newer branches.  I.e., if you add a new entry point in say
the 4.1 branch and release that, and you link a program that uses this
new entry point with the 4.1 lib, and then you try to run it with a
4.2 lib (that claims to be newer than any 4.1 lib), you have a
problem.

OTOH, you don't want a program linked with an early 4.2 lib to get the
impression that it can run with a late 4.1 lib, so you don't want to
late 4.1 lib to look newer.

So, you see, there's no 100% safe solution for dealing with forks, so
I guess my suggestion above is as good as it gets (and no worse than
what we have now), without using the fancier library compatibility
mechanisms available on some OSs that are not exposed by libtool in a
way that you could take advantage of to overcome this particularly
tricky case.  Oh well...

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}