Re: Shared library versioning

[Lasse Collin]

On 2011-06-17 Charles Wilson wrote:
> On 6/16/2011 2:50 PM, Lasse Collin wrote:
> > 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.

How is major:minor:revision in libraries related to package versions?

> > 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.

People can do stupid things with any version numbering scheme. :-)

> 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).

Most operating systems use either nothing, major, major.minor, or 
major.minor.revision for shared library versioning and share the rules 
when to increment those numbers. Libtool thinks that some are different 
and thus has its own versioning scheme, but I don't believe yet that 
Libtool is correct on these operating systems.

So current:revision:age isn't as simple as major:minor:revision because 
people are more familiar with the latter. Libtool's manual explains 
current:revision:age well, but at least I got immediately curious how it 
maps to major:minor:revision because obviously it has to do that at 
least on GNU/Linux.

Example: current:revision:age is 5:3:1 and a new function is added. You 
get 6:0:2. Fix a bug and get 6:1:2. Then you break the ABI and get 
7:0:0. The order of the numbers is perhaps what takes most of the extra 
thinking time for me. If it were 5:1:3 -> 6:2:0 -> 6:2:1 -> 7:0:0, it 
would be clearer in my opinion.

If no operating system needs current:revision:age, using 
major:minor:revision would be nicer since more people are already 
familiar with the rules of that versioning scheme. Since people make 
mistakes even with major:minor:revision, the probability of mistakes is 
unlikely to be lower with current:revision:age with which people aren't 
familiar outside Libtool.

> But the key point is, *library* version numbers should
> be entirely unrelated (*) to the *package* version numbers (**).

Of course. I have never suggested anything else.

> (**) 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.

At that point, Debian had bumped major to 2. Other distros might have 
had other versions. If I had tracked the ABI breakages in development 
versions, current in -version-info would now be close to a three-digit 
number. Probably I wouldn't have remembered to update the version number 
on every ABI breakage. So it was much simpler to not track the ABI 
breakages until a stable release.

People were packaging Git snapshots so incrementing current only for 
official releases (to keep version numbers low) wouldn't have worked so 
well, although I admit that I made releases far too rarely. There were 
ABI breakages between 4.999.9beta and 5.0.0, so even if I were 
incrementing the library version only when making a release, I would 
have had to increment the version for 5.0.0 anyway.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode