Hi Richard, * Richard B. Kreckel wrote on Sun, Sep 20, 2009 at 10:28:25PM CEST:
I just figured I would like to make a new release of CLN. I then realized that setting version numbers has always been confusing me. Until now, I've never cared as much about this as I should, but this should some day get clarified.
The configure.ac file in CLN says: [ pretty much a copy of 'info Libtool "Updating version info"' ]
dnl * increment CL_REVISION,
dnl * if any functions/classes have been added, removed or changed, dnl increment CL_CURRENT and set CL_REVISION to 0,
dnl * if any functions/classes have been added, increment CL_AGE,
dnl * if backwards compatibility has been broken, set CL_AGE to 0.
OK so far.
dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in
dnl libcln.so.$(CL_CURRENT)-$(CL_AGE)
This is not necessarily true. It only holds on some systems, but not on all.
Okay, let's see. I've fixed a function that used to segfault and I've added support for a platform that was not supported before. I increment CL_REVISION.
OK.
Have I added, removed ro changed a function or class? I'm not sure. Interface-wise not. But I've changed functionality (it doesn't crash any more). So I increment CL_CURRENT to 7 and set CL_REVISION to 0.
Why? I'd only do that if the crash was part of previously documented behavior, i.e., intentional, and that users of the old version of your library rely on it crashing, and need to change their code and recompile/relink to use the new version. If all you've done is a bugfix then I don't see why your interface has changed. So all you do from the previous release is bump up CL_REVISION, and not touch the rest. The whole thing is pretty simple if you consider that there are three possible kinds of reactions from your users to changes from you: 1) Programs using the previous version may use the new version as drop-in and programs using the new version can also work with the previous one. IOW, no recompiling, no relinking needed. In this case, bump REVISION only. 2) Programs using the previous version may use the new version as drop-in but Programs using the new version may use APIs not present in the previous one. IOW, a program linking against the new version may fail with "unresolved symbols" if linking against the old version at runtime: REVISION = 0, bump CURRENT and AGE. 3) Programs may need to be changed, recompiled, relinked in order to use the new version. REVISION = 0, bump CURRENT, AGE = 0. HTH. We should probably add something like that to the Libtool manual, but for that I should think about this a bit more, in case I overlooked something. Cheers, Ralf