[v3] update libtool_VERSION

[Benjamin Kosnik]

> > So, why the insistence that we change the way we versioning now?
> 
> If you don't follow the recommended practice, you're breaking library
> compatibility on some systems.  Some shared library systems are more
> general than major.minor, and libtool can accommodate them.  By not
> following the recommended practices, you may enable some libraries to
> pass for compatible ones that aren't, and vice-versa, depending on the
> details of the system.  That's why the procedure is in place.

OK.

> > If possible, I suggest you revisit this point in the future when
> > SONAME gets bumped and we have a fresh start.
> 
> You can start following the recommended procedure any time you like.
> You don't have to wait for a major bump to start benefitting those
> systems on which the very notion of major doesn't apply.

I'm willing to try strict autotools versioning.

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?

-benjamin