On 12/31/2013 08:10 AM, Mathias Gaunard wrote:
On 30/12/13 18:32, Peter A. Bigot wrote:
*) If a module has a module-specific version number, should it be expected to provide that version number in a standard location and name so that preprocessor directives interrogate and adapt user code based on it? What mechanism should be used for this?
git describe --tags could be the right mechanism for this. If you're on a tag, it gives you tagname. Otherwise it gives lasttagname-numberofcommitssincethen-sha1.
That's fine at the command line or scripts that produce an archive. The need here is to be able to tell within code whether a feature is available based on the version of the module. E.g: #if BOOST_TIMER_VERSION < BOOST_VERSION_NUMBER(3,5,2) /* provide local workaround */ #else /* use feature added in version 3.5.2 */ #endif
My opinion: Absolutely. If the module is named timer (sorry I keep picking on that module), then I would like to see:
I have a question about this:
Should module-specific version numbers start at 1.56, or whatever the last Boost version before modularization was, or should they start at 1.0?
Seems like something that Boost would normally leave up to the module maintainer, including whether the scheme selected is a two-value, three-value, or date-based versioning. I can imagine cases where a Boost library provides a wrapper around an external library that has its own versioning, and the two should be correlated. Peter