Re: [v3] update libtool_VERSION

[Benjamin Kosnik <bkoz at redhat dot com>]

> > Well, just adding interfaces (what is going on here) means increment
> > age according to your link, which is what this patch did.
> 
> The patch increments the revision, not the age.  The referenced node
> says:
> 
>   3. If the library source code has changed at all since the last
>      update, then increment REVISION (`C:R:A' becomes `C:r+1:A').
> 
> This is what you have done.

Um, ok.

>  But there are more steps:
> 
>   4. If any interfaces have been added, removed, or changed since the
>      last update, increment CURRENT, and set REVISION to 0.
> 
>   5. If any interfaces have been added since the last public release,
>      then increment AGE.
> 
> Both of them apply here too.  The steps should be applied in that
> order as long as the conditions apply.

I see your point, and agree that if 4.3.0 was release one, and trunk
was release two, and we used canonical libtool versioning, it should be
7:1:0. Point made.

But libstdc++ doesn't use canonical libtool versioning. We've
added a lot of interfaces without incrementing CURRENT. People
insist on versioning the trunk, when it's not a public release. Perhaps
libstdc++ should be a libtool poster child, but it certainly
isn't and hasn't been so far.

And we're on release 11...

So, why the insistence that we change the way we versioning now? I'm
not quite sure why you are coming from on this. What's so special
about the next release? Why not at 3.4.1? The way I see it, if we are
going to use strict canonical libtool versioning, it should be something
like 15:2:9 (taking retroactive changes into account.)

This is a relatively minor point, IMHO. Dynamic linkers on gnu systems
are happy with either. If possible, I suggest you revisit this
point in the future when SONAME gets bumped and we have a fresh start.

best,
-benjamin