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? --Beman
In gitflow, hotfix/ is dedicated to branch followed immediately by hotfix
release.
But, not every bugfix leads to release, so no dedicated prefix for such
utility branches serving bug fixes only.
Hence, hotfix and bugfix are not equivalent names - just pointing this out.
Mateusz Loskot, http://mateusz. loskot.net
(Sent from mobile, apology for top-posting or broken quotes)
On 10 Dec 2013 17:04, "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?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Dec 10, 2013 at 1:50 PM, Mateusz Loskot
In gitflow, hotfix/ is dedicated to branch followed immediately by hotfix release. But, not every bugfix leads to release, so no dedicated prefix for such utility branches serving bug fixes only.
Hence, hotfix and bugfix are not equivalent names - just pointing this out.
Ha! Interesting distinction. So we should use both, as appropriate. I've updated the page. Thanks, --Beman
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
On 10.12.2013 21:04, Beman Dawes wrote:
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"
Speaking about which, does anybody find it awkward that 'master' is adjective, whereas 'develop' is a verb? Would using 'stable' or 'unstable' be more reasonable? Or it's just something I don't grasp about English grammar? Thanks, Volodya
On 11 December 2013 07:42, Vladimir Prus
On 10.12.2013 21:04, Beman Dawes wrote:
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"
Speaking about which, does anybody find it awkward that 'master' is adjective, whereas 'develop' is a verb? Would using 'stable' or 'unstable' be more reasonable? Or it's just something I don't grasp about English grammar?
AFAIU, 'develop' is used as short form of 'development'. I don't like the verb-like form either. Similarly, CMake uses 'maint' for maintenance, they also use 'next' instead of gitflow's 'develop' http://www.cmake.org/Wiki/CMake/Git Best regards, -- Mateusz Ĺoskot, http://mateusz.loskot.net
Vladimir Prus
On 10.12.2013 21:04, Beman Dawes wrote:
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"
Speaking about which, does anybody find it awkward that 'master' is adjective, whereas 'develop' is a verb? Would using 'stable' or 'unstable' be more reasonable? Or it's just something I don't grasp about English grammar?
FWIW, 'master' is usable as a verb too. To develop. To master. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On Wed, Dec 11, 2013 at 2:42 AM, Vladimir Prus
On 10.12.2013 21:04, Beman Dawes wrote:
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"
Speaking about which, does anybody find it awkward that 'master' is adjective, whereas 'develop' is a verb? Would using 'stable' or 'unstable' be more reasonable? Or it's just something I don't grasp about English grammar?
I also found "master" to be somewhat awkward, but the argument for retaining the Git Flow default names is a strong one, as it eliminates the need to teach a new set of names to the many folks that already know Git Flow names, and means that a lot of training and tutorial material out on the web applies directly to Boost. Also note that "develop" may be stable too, if that is the policy of the individual library. --Beman
participants (5)
-
Alexander Lamaison -
Beman Dawes -
Cox, Michael -
Mateusz Loskot -
Vladimir Prus