On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot
On 12/26/2013 05:09 PM, Beman Dawes wrote:
See
https://svn.boost.org/trac/boost/wiki/StartModMaint# 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.
Updated: https://svn.boost.org/trac/boost/wiki/StartModWorkflow#Releasetags https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas... https://svn.boost.org/trac/boost/wiki/StartModMaint #Lightweightlibraryreleasehttps://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas...
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
header which has: #define BOOST_TIMER_VERSION_MAJOR 1 #define BOOST_TIMER_VERSION_MINOR 2
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 changes.
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! --Beman