Boost logo

Boost :

Subject: Re: [boost] [git] tagging in modules
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-30 12:02:58

On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot <pab_at_[hidden]> wrote:

> On 12/26/2013 05:09 PM, Beman Dawes wrote:
>> See
> >
> Lightweightlibraryrelease
> Not relevant to the original thread, but since I just noticed it:
> git-push by default does not push tags: you need to specifically ask for
> the tag to be pushed (by name), or use --tags. So this sequence does
> nothing visible:
> git tag -a 1.2
> git push
> Personally I'd prefer if tag symbols were a little more informative than
> "1.2", and followed a pattern that places them in a namespace reserved for
> the module, such as timer-1.2. Because tags aren't normally pushed,
> they're useful for individual developers to use as markers. However,
> git-pull will automatically retrieve tags attached to commits that are
> fetched unless --no-tags is given, so if a repository (from boostorg, or
> another developer) defines (or moves) a tag it might overwrite your local
> tag without warning. So it's important to know what tags you can expect
> might conflict with those in a remote repository to avoid conflicts.


> I'd also really like to see any module that uses internal versioning also
> provide a mechanism by which code can determine which version is being
> used. E.g., for the above there ought to be a <boost/timer/version.hpp>
> header which has:
> Otherwise I'm not seeing any value for module-level version tags in the
> repository. Matter of taste, though.

While I'm sympathetic, we should get comments and buy in from library
maintainers before recommending this. Are a lot of libraries already doing
something similar? If so, what? And do we follow Rene's suggestion and
recommend Predef? Could you please start a separate discussion with a
subject that let's maintainers know this is affects them? Thanks!

There is a tangentially related issue: The git and modular boost related
docs are being developed without any reference to or updating of existing
developer documentation. We need to get that underway. Ditto web site

> I would expect, on superproject release, that each module would continue
> to receive a boost-X.Y tag marking the module commit that corresponds to
> the submodule SHA1 used for the release. This is another reason to make
> sure module-level tags are clearly distinguished (lest somebody think the
> tag corresponds to a boost version rather than a module version).

Sounds about right, but we would need to work out the mechanics. Who does
the tagging? A script release managers run?

Thanks for the corrections and suggestions!


Boost list run by bdawes at, gregod at, cpdaniel at, john at