[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared library versioning
From: |
Lasse Collin |
Subject: |
Re: Shared library versioning |
Date: |
Fri, 17 Jun 2011 12:26:59 +0300 |
User-agent: |
KMail/1.13.7 (Linux/2.6.39-ARCH; KDE/4.6.3; x86_64; ; ) |
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
- Re: Shared library versioning, (continued)
- Re: Shared library versioning, Mike Frysinger, 2011/06/10
- Re: Shared library versioning, Lasse Collin, 2011/06/10
- Re: Shared library versioning, Bob Friesenhahn, 2011/06/13
- Re: Shared library versioning, Lasse Collin, 2011/06/14
- Re: Shared library versioning, Bob Friesenhahn, 2011/06/14
- Re: Shared library versioning, Lasse Collin, 2011/06/14
- Re: Shared library versioning, Peter O'Gorman, 2011/06/14
- Re: Shared library versioning, Mike Frysinger, 2011/06/14
- Re: Shared library versioning, Lasse Collin, 2011/06/16
- Re: Shared library versioning, Charles Wilson, 2011/06/16
- Re: Shared library versioning,
Lasse Collin <=
- Re: Shared library versioning, Charles Wilson, 2011/06/17