Re: [boost] Versioning of individual modules

Subject: Re: [boost] Versioning of individual modules
From: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-31 09:49:07

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