On Tue, Dec 10, 2013 at 10:04 AM, Beman Dawes
I've been working on Modular Boost Library Workflow Overview.
See https://svn.boost.org/trac/boost/wiki/StartModWorkflow
In addition to the requirement for "master" and "develop", there is strong encouragement for naming conventions if several other branches are present:
* feature/descriptive-name for feature branches. For example, feature/add-roman-numeral-math. * bugfix/descriptive-name for bug-fix branches, including hotfixes. For example, bugfix/ticket-1234-crash-if-result-negative * release.n.n.n for release staging branches. For example, release.1.56.2.
Should "bugfix/..." be changed to "hotfix/...", since that's the name given in the Git Flow blog posting? While I see lots of advantages to following Git Flow naming, I've never been sure what "hotfix" means. It seems weird to call a low-priority cosmetic fix a "hotfix".
What is the usual practice for description names? Can they include spaces? Is there any reason to recommend spaces vs underbars vs hypthens?
Are there any other branches we should recommend names for?
You may want to include the name of the "product" in the release naming
conventions, e.g.
boost-1.56.2
accumulator-x.y.z
so that release branches/tags of a library can be distinguished from boost
releases in a libraries submodule. Or will individual libraries not contain
boost branches/tags?
If boost-1.56.2 is the branch, what will be the naming convention for the
tag on the merge commit into master. Will the branch be deleted and the tag
be identical? Or possibly have the branches format be boost-X.Y (so work
for the next release of the branch goes here, but that implies long-lived
release branches) and when the branch is merged into master, a tag of
boost-X.Y.Z is used.
Maybe ticket/
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost