Please consider versioning the library and the ABI
- Dominant language
- C++
- Stars
- 221
- Forks
- 31
- PR merge metrics
- No merged PRs in 30d
Description
Please consider versioning the project as a whole and tagging releases. This would make things much easier for anyone packaging and redistributing animx. (I want to add an `animx` package to Fedora Linux.)
Similarly, it would be really helpful if shared library versioning could be added. [CMake makes this pretty easy](https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html). Typically, especially for projects with C APIs/ABIs, the ABI version is a single integer that starts at `1` and is incremented each time a backwards-incompatible ABI change is made (like removing a function, or changing the type of one of its arguments). The value is [encoded in the `SONAME` field of the shared library file using a linker flag](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_soname_handling), e.g. `N=1; gcc $CFLAGS -Wl,-soname,libfoo.so.$N -o libfoo.so.$N`. Then an unversioned symbolic link would be created that points at the versioned shared library. Again, CMake can handle all of this. Some projects with C++ APIs/ABIs use dotted `SONAME` versions, e.g. library version `1.2.3` has `SONAME` version 1.2 if ABI stability is guaranteed in patch releases. Others can’t guarantee any ABI stability at all, and use the entire version number as the `SONAME` version. This is still useful, as long as it reflects reality.
All of this is important for packaging animx in Linux distributions. In the case of Fedora, [we can add the `SONAME` version downstream if necessary](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning), but one managed upstream is much better, as it benefits everyone and ensures consistency across distributions.
Contributor guide
Assessment
This issue has not been assessed yet.