Re: Shared library versioning

[Charles Wilson]

On 6/16/2011 2:50 PM, Lasse Collin wrote:
> About -version-info vs. -version-number: *If* it turns out that all 
> operating systems supported by Libtool should use a versioning style 
> that is essentially the same as version_type=linux, could 
> -version-number become the recommended option to set the library 
> version?

Oh, please god, no.  On windows and cygwin, where (a) symlinks can't be
used for DLL resolution, and (b) there is no ld.conf/ld.so to manage
versions, we REALLY depend on a sane numbering system, because it gets
embedded into both the name of the DLL and its clients. (Remember:
unlike the *nix schemes, no redirecting via symbolic links is allowed)

> Major:minor:revision is easier to understand than current:revision:age, 

Major:minor:revision artificially entangles package release numbering
with API/ABI changes.  Typically when one 'goes up' so does the other,
but not always -- and not by the same increment.

And what if...your package has two different libraries, and only one of
them had an ABI change?

> which in practice is (major+minor):revision:minor. 

ONLY if you slavishly follow the one particular scheme for your package
version numbering.  I'll point out that linux itself (the kernel)
doesn't follow that scheme.  Nor does TeX.  And what if you increment
package $major because your *application* has had a major new
functionality addition, AND its command line interface has changed...but
the DLL hasn't changed at all?  Why should the DLL soname be changed
just because one of its clients has a new set of cmdline options?


Actually, that particular scheme ('bump major for ABI breaks; bump minor
for significant new features, bump micro for bugfixes') is honored more
in the breach than actually followed...Many projects appear to
(accidentally?) break library ABIs with minorver updates...and sometimes
majorver updates don't modify the ABI at all but simply represent a big
new feature addition -- or a promotion to 'stable' (**)

> Using a scheme that 
> is easier to understand would hopefully reduce mistakes in library 
> versioning.

No, it just ensures that the version numbers associated with shared
libraries will ALSO be infected with marketing-induced version inflation.

current:revision:age is VERY simple -- if you bother to read the libtool
manual (a tall order, for some project maintainers, I'll grant you).
But the key point is, *library* version numbers should be entirely
unrelated (*) to the *package* version numbers (**).

(*) except in the most vague sense of 'when ones goes up, the other one
might go up too. Maybe.'

(**) Which is why I was mildly annoyed when xz-5.0-final was published,
and included a wholly unnecessary "version bump" from 0:0:0 to 5:0:0.
Granted, it helped *me* out because I was already using 1:0:0 on cygwin
due to an ABI change in the prereleases.  Anyway, my annoyance was only
mild, because you had announced that soname plan LONG before the event,
so we were well prepared for it.

--
Chuck