If that one person isn't willing to deal with it then that person shouldn't be writing libraries. :)
Never said that...
I will take a look into debian-mentors, but I've just talked to the upstream author and can now explain the reason of his choice.Unfortunately that doesn't make his reasoning right. :)
Nor that. I merely meant that I understood why he chose this kind of SONAME.
The thing is that every change in a template class or function in the shared library will lead to an ABI change (except some rare cases). Since the majority of the modifications are made in this section of the library I don't find absurd to modify the SONAME on each new compilation of the library (only of course if modification has been made since last compilation). This goal of all this is to make the update of SONAME as far as I can automatically. The idea now is to keep two records, one with the sources version and one with the current soname. On each modification (and CVS commit) of the sources, if changes have been made to the library's source files, SONAME is increased, sources version is always incremented. The SONAME will be (as inspired from libginac) in the following form :The thing is that the library is written in C++ and makes heavily use of templates which means that even a small change in the code, that doesn't change the ABI, might lead to incompatibility.There's no 'might' about it... Either it changes the ABI or it doesn't. ABI does mean more than just symbols though and so, yes, you do have to be careful and realize when you make an ABI change.
lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage) or maybe lib*.so.XY (format that is used today by the upstream author) Alexis Papadopoulos