[cctbxbb] Module versioning (was Re: Debian Package)

[Radostan Riedel]

On Sat, 01. Sep 03:33, Luc Bourhis wrote:
> Now going back to patch 0007-adding-shlib-versioning, is it correct that we would just need to do:
> 	env.Append(SHLINKFLAGS= [ "--version-info=c.r.a" ]
>  for the env that build a particular .so? Well, that would be for gcc and clang only of course. To be cross-platform  I would suggest adding a pseudo-builder SetVersionInfo(vers) that does the right thing on Unix and nothing on Windows (for the time being, as perhaps there is a similar mechanism with msvc).
That's a good idea. I'll try to rework by patch to ease everything up.
> 
> But your well-written patch and that little sugar are the easy part as they are of the write once, reuse forever nature. We need a workflow here and the two extremes would be as follow.
> 
> 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?

> 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.