Revert soname change #306
Revert soname change #306
Conversation
The soname is equal to current minus age. In version 2.31.0 current is 2 and age is set to 0. In versuin 2.31.1 current is 2 and age is set to 1. This means the soname goes backwards from 2 to 1. The full library version changes from 2.0.31 to 1.1.31 The soname should not go backwards, so this soname change looks like a mistake that should be reverted. The current, revision, age for a library should change in one of three ways: 1) increase current by one, reset revision and age to 0. 2) increase current by one, reset revision to 0 and increase age by 1. 3) increase revision by 1, retain the values of current and age. 1) is for non-backward compatible changes to the library (changes or removals to the old ABI). Soname changes and applications using the library must be recompiled. 2) is for when there are ABI additions to the library, but no ABI changes or removals. Application compiled against the old version of the library don't need to be recompiled, and the soname (current minus age) does not change. 3) is for minor updates with no ABI additions, changes or removals. The major, minor, patch version of the software project should not be used as current, revision, age for the library. Especially true for using the patch version as age, because that means the soname goes backwards for patch releases as happened here. Signed-off-by: Mattias Ellert <[email protected]>
|
@ellert many thanks for flagging this. I will fix delete the release, fix and release again. Looks like REVISION will need to be 32, even though the library (semantic) version is 2.31.1 |
Actually, I'd say it's ok to leave it as REVISION=31 |
Technically, the important thing is the soname, which only depends on current and age. So nothing will break if you leave the revision unchanged. If the libraries for every release should be parallel installable in the same directory they must have different revisions, but this is usually not a requirement. |
|
The PR is now merged, thanks for flagging and fixing this. |
The soname is equal to current minus age.
In version 2.31.0 current is 2 and age is set to 0.
In versuin 2.31.1 current is 2 and age is set to 1.
This means the soname goes backwards from 2 to 1.
The full library version changes from 2.0.31 to 1.1.31
The soname should not go backwards, so this soname change looks like a mistake that should be reverted.
The current, revision, age for a library should change in one of three ways:
(1) is for non-backward compatible changes to the library (changes or removals to the old ABI). Soname changes and applications using the library must be recompiled.
(2) is for when there are ABI additions to the library, but no ABI changes or removals. Application compiled against the old version of the library don't need to be recompiled, and the soname (current minus age) does not change.
(3) is for minor updates with no ABI additions, changes or removals.
The major, minor, patch version of the software project should not be used as current, revision, age for the library. Especially true for using the patch version as age, because that means the soname goes backwards for patch releases as happened here.
Did you intend to change the soname for this patch release? At least the soname should not go backwards.