Hi Radostan, I took the liberty to fork the thread as it has become far too long.
It's not well seen to package a shared library without so-versioning. I can imagine some developers building software based on a shlib without versioning and in a few years upstream might change the API and this leads to weird errors during runtime and nobody knows why.
About the version number this is something upstream needs to decide. From libtools manual[1]:
current:revision:age """ Start with version information of `0:0:0' for each libtool library. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 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 current, and set revision to 0. If any interfaces have been added since the last public release, then increment age. If any interfaces have been removed since the last public release, then set age to 0. """
[...]
OK. But this could be an issue. Would be nice if upstream were aware of the versioning and would start to maintain it. In all cases versioning is an important indicator for API changes.
Right, I am willing to learn! But before, a comment is in order: what about our Python code? That's a large part of the cctbx and it seems to me the very same reasonings justifying so-versioning applies to Python modules and packages: API's change in incompatible ways on a regular basis. I know many projects do maintain a __version__ string. Is there also some sort of official policy here in the Linux software community? Imho it would be meaningless for the cctbx to invest time in proper so-versioning if we do not version Python because in many instances, a change in the Boost Python interfaces will go hand-in-hand with changes in the Python modules. Now onto so-versioning per se. I am afraid I find the libtool manual excerpt you quoted totally obscure. If you understand it, could you tell me what the next version number would be if we started with e.g. 1.2.3 and then i. change some implementation but not API; ii. added new API without touching existing ones; iii. removed some API without changing existing ones or adding new ones; iv. changed existing API's without deleting any or adding any? Best wishes, Luc