update soversion with each minor release
What is the problem this feature will solve?
Currently the ada library uses semantic versioning. https://semver.org/
If you add functionality, without breaking the API, you usually issue a minor release, and this means that the version (major version) remains the same.
Semantic versioning is not compatible with Unix versioning because Unix requires that the compiled (possibly shared) library be interchangeable between versions.
What is the feature you are proposing to solve the problem?
Consider adding an soversion that gets incremented with each minor release (using the semantic convention).
Currently, the release script does not update the soversion. The soversion should get incremented with minor release. Currently, it does not get incremented at all unless there is a major release:
https://github.com/ada-url/ada/blob/a383f41041c112c6e370c6877197be0b8756b5f6/tools/release/lib/versions.py#L7
That is, currently the soversion is just the major semantic version, but that's not correct. All librairies with the same soversion must have the same exported functions with the same function signatures.
What alternatives have you considered?
I don't think that there is a sane alternative short of dropping the semantic versioning and adopting Unix versioning where each. That would mean making a major release the minute a new function is added.
As a debian package maintainer, I experimented a bit with abigail-tools. Running that kind of script just after a build could help a lot detection of ABI breakage:
set -xe
abidw --header-file include/ada.h obj-$(DEB_HOST_MULTIARCH)/src/libada.so > abi.xml.new
if [ -f abi.xml ]; then
abidiff abi.xml abi.xml.new
fi
mv abi.xml.new abi.xml
@kapouer Intriguing.
Example of output when upgrading from 3.2.0 to 3.2.7:
+ abidw --header-file include/ada.h obj-x86_64-linux-gnu/src/libada.so
+ [ -f debian/abi.xml ]
+ abidiff debian/abi.xml debian/abi.xml.new
Functions changes summary: 2 Removed, 0 Changed, 2 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
2 Removed functions:
[D] 'function std::string ada::to_string(ada::encoding_type)' {_ZN3ada9to_stringB5cxx11ENS_13encoding_typeE}
[D] 'function bool std::all_of<charconst*,bool(*)(char)noexcept>(const char*, const char*, bool (*)(char))' {_ZSt6all_ofIPKcPDoFbcEEbT_S4_T0_}
2 Added functions:
[A] 'function std::string_view ada::to_string(ada::encoding_type)' {_ZN3ada9to_stringENS_13encoding_typeE}
[A] 'method void ada::url::set_scheme(std::string&&)' {_ZN3ada3url10set_schemeEONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE}
make[1]: *** [debian/rules:26: execute_after_dh_auto_build-arch] Error 12
make[1] : on quitte le répertoire « /home/dev/Software/debian/ada-url/salsa »
make: *** [debian/rules:12: binary] Error 2
dpkg-buildpackage: erreur: le sous-processus debian/rules binary a retourné l’état de sortie 2
I'm no c++ programmer, but that kind of report could be used by ada-url contributors to preemptively ensure there are no ABI breakage ?