Re: Shared library versioning

[Charles Wilson]

On 6/17/2011 5:26 AM, Lasse Collin wrote:
> 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.

FYI, this is actually the recommended approach (at least, during periods
rapid development where the API changes a lot, or /between/ official
tarball releases of the source).  However, I find this "recommended
practice" a bit risky, because after three months of development one is
likely to /forget/ that patch ae76b23f from six weeks ago changed the
API, when it comes to update -version-info and package up the new -src
tarball.

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

Sure, I get/got that.  It's just that, /ideally/, you would have simply
incremented to 1:0:0.  However, you chose to increment to 5:0:0 for two
reasons -- one good, and one somewhat misguided IMO.  The good reason:
to leave "room" for people like me (cygwin, mingw) and debian, who had
been tracking pre-releases and had 'used up' soname 1 and 2 (and
possibly more) in addition to the "official" prerelease soname 0.  The
bad reason: let's jump to soname 5 because the package version number is
5.0.

--
Chuck