Closed lgbaldoni closed 12 months ago
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:
0:0:0
for each libtool library.c:r:a
becomes c:r+1:a
).c
, and set r
to 0
.
a
.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?
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}'
Hope that helps.
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?
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.
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!
Right now when building the shared library, it comes out as .so.1.0.4.