On Sat, 1 Sep 2012 11:35:04 +0200
Radostan Riedel
1. Each and every cctbx developer becomes aware of so-versioning. Let's say a module is at 2.3.4, so we have env.SetVersionInfo(vers="2.3.4") and then a change is made to the C++ code. The developer responsible for that change should then figure out the new c.r.a and then add a comment env.SetVersionInfo(vers="2.3.4", #next release# vers="c.r.a") It would then be easy to automate an edit en-masse before release that would change that line and all its sisters to env.SetVersionInfo(vers="c.r.a") That's basically a formalised version of your proposition in your answer to Johan earlier.
2. Cctbx developers would not care about so-versioning and before a Debian release, the cctbx Debian maintainers would go through each call to SetVersionInfo to set the right c.r.a, based on a careful examination of the commits, complemented by asking questions to the core cctbx developers (or simply open questions on this forum). I'd of course like the first extreme better. For starters it would be great if everyone feels responsible for the "current" number. I'm not a c++ developer and I don't know if thats easy?
To my opinion the first solution whould be the best one also for other distribution. Indeed this is a "social" problem, developpers of the C++ librarty should learn about ABI/API compatibility like expected by most distributions when it comes to do some "long term" support into an integrated environment. The person who did the change is the only one which know the implication of the changes. Now during the build of a Debian package we have some tools that could detect API modifications and the build can fail if a library without a so number bump, remove a symbols. So it is a round trip collaboration, we can check if a so bump is requiere by a build of the futur next stable release, Identify the problem and explain to the person in charge of the C++ library how to modify the corresponding so number. After a few roundtrip (release) I think that peoples whould understand how to deal with thoses numbers.
There are relatively very few shlibs compared to Python modules. Keeping track of the version of all of the latter by hand would be an enormous amount of work. I don't think we can get it done cheaply with some automatic keyword expansion if we want proper major.minor.patch or worse something as involved as so-versioning. Maybe it can be good to look on other projects how they are doing this. As a python developer I'm always expecting different API's when it comes to new upstream versions. I checked the policy for Debian and there seems to be nothing special in versioning extensions and modules. Maybe Justin can tell us something about Gentoo. I'd say we don't need to worry about it for now.
Yes excepted if you distribut python extension used by other third
party to build other extension. A good example is the python-numpy
package. It was a nightmare for distribution before they introduce an
API and ABI number.
the public C API/ABI of this extension is now following a sort of so
number and when someone build a package relying on this python-numpy
extension the dh_numpy helper generate the right binay dependencies,
based on the ABI number maintained by the numpy upstream.
there is a dependency on python-numpy-abix. Exemple for the scipy package
Package: python-scipy
Version: 0.10.1+dfsg1-4
Installed-Size: 34405
Maintainer: Debian Python Modules Team