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

[Luc Bourhis]

Dear Radostan Riedel,

> Hope that's more clear now.

Crystal clear! Thanks for the explanations.

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

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

The reality is that it may end up in-between those extremes. The C++ code tends to be much more stable than the Python code. Thus the effort of working out the so-versioning changes is less daunting than it seems. 

I am much more worried about Python if it comes to that:

> I don't think there is anything special about versioning python extensions. It
> should be versioned by distutils like the module too. But maybe Baptiste knows more on that.

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.

Best wishes,

Luc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20120901/b5c7d9ce/attachment.htm>