Match package version in soversion

[lgbaldoni]

Right now when building the shared library, it comes out as .so.1.0.4.

[hhromic]

Hey @lgbaldoni, thanks for this contribution and for bringing to my attention that I was doing libtool versioning wrong 🙈. And also apologies for the really late reply. I hope you are still around for the feedback.

I re-read the libtool documentation regarding updating version-info which suggests the following update rules:

• Start with version information of 0:0:0 for each libtool library.
• If the library source code has changed at all since the last update, then increment revision (c:r:a becomes c:r+1:a).
• If any interfaces have been added, removed, or changed since the last update, increment c, and set r to 0.
  • If any interfaces have been added since the last public release, then increment a.
  • If any interfaces have been removed or changed since the last public release, then set a to 0.

Using the above rules, I reviewed all the library release changes to re-calculate the correct libtool version-info.

Release Version	Used version-info	Correct version-info
v1.0.0	none	0:0:0
v1.1.0	1:0:0	1:0:0
v1.2.0	1:2:0	2:0:1
v1.3.0	1:3:0	3:0:0
v1.3.1	1:3:1	3:1:0
v1.4.0	1:4:0	3:2:0

Therefore, I believe that for release version v1.4.0, the correct libtool version-info should be 3:2:0 and not 5:0:4. Would you agree or I a calculated/interpreted something wrong?

[lgbaldoni]

I dug up my notes from 4 years ago. To be honest, I could never understand the rationale behind the libtool syntax too well, but if one merely wants to produce a specific soversion, this empirical formula (which I can't say is formally correct) appears to do the trick:

awk -F "." '{print $1+$2 ":" $3 ":" $2}'

• field 3 must never be higher than field 1
• major version seems to be the difference between field 1 and field 3
• minor version is field 3
• patch version is always field 2

Hope that helps.

[hhromic]

Thanks for replying and for going back in time and find your notes on this PR! Much appreciated! I also have to admit it is quite hard to grasp the versioning scheme for libtool at first.

I just found out a libtool version calculator here: https://www.pakin.org/~scott/ltver.html

I reviewed again all the code changes per version and using that calculator I obtained the following version-info table:

Release Version	Used version-info	Correct version-info
v1.0.0	none	0:0:0
v1.1.0	1:0:0	1:0:0
v1.2.0	1:2:0	2:0:1
v1.3.0	1:3:0	3:0:0
v1.3.1	1:3:1	3:1:0
v1.4.0	1:4:0	3:2:0

Which matches the initial table I manually calculated before.

The formula you shared has one minor issue though, which is that version v1.0.0 (first public release) is 0:0:0 in libtool version-info. Apart from that, the formula seems appropriate but it assumes that semantic versioning has been done correctly across versions, which I sadly now realised it is not the case for this library 🙈. There were interface changes that I did not reflect correctly in the released semantic versions.

If I fix your formula to account for the first public version offset:

awk -F "." '{print $1+$2-1 ":" $3 ":" $2}

and I was to follow semantic versioning strictly, your formula and the calculator both give the following table:

Release Version	Used version-info	Correct version-info
v1.0.0	none	0:0:0
v1.1.0	1:0:0	1:0:1
v1.2.0	1:2:0	2:0:2
v1.3.0	1:3:0	3:0:3
v1.3.1	1:3:1	3:1:3
v1.4.0	1:4:0	4:0:4

My opinion is that for consistency we should use 4:0:4 as if semantic versioning was followed strictly until now, and start following it strictly from now on :)

What do you think? Would you update your PR to use 4:0:4 so I can merge it?

[lgbaldoni]

My opinion is that for consistency we should use 4:0:4 as if semantic versioning was followed strictly until now, and start following it strictly from now on :)

What do you think? Would you update your PR to use 4:0:4 so I can merge it?

Troble is that with version-info 4:0:4 the resulting soversion is 0.4.0. EDIT: for any linux distribution building this as shared library it would be a downgrade, requiring a patch to avoid confusion.

[hhromic]

Troble is that with version-info 4:0:4 the resulting soversion is 0.4.0.

Ah, I forgot to consider that indeed. Good call. I went again to manually check the generated library filenames for all the releases of the library and they can be seen in the table below.

Release	version-info	Library Filename
v1.0.0	none	libe131.so.0.0.0
v1.1.0	1:0:0	libe131.so.1.0.0
v1.2.0	1:2:0	libe131.so.1.0.2
v1.3.0	1:3:0	libe131.so.1.0.3
v1.3.1	1:3:1	libe131.so.0.1.3
v1.4.0	1:4:0	libe131.so.1.0.4

As can be seen, I have been doing the libtool versioning quite wrong, specially for version v1.3.1 🙈.

For library compatibility, the important thing is that the library soname remains as libe131.so.1 (until a new major version is relesaed) and the version numbers increase accodingly for minor/patch.

That being said, and to reduce confusion from libtool versionsing, I think is a good idea to adopt parity between release version numbering and the created library filename as you propose in this PR 👍.

I will merge this now, thanks for the interesting discussion and keeping up with this. Appreciated!