On Thu, Jan 2, 2014 at 3:47 PM, Peter Dimov
Beman Dawes wrote:
See https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow
Comments welcome!
"Changes from original proposal" says "Releases branched from "master", per Git Flow."
But that's not how Git Flow works. Release branches are created from "develop" and merged to "master". Only hotfix branches are created from "master".
Reference: http://nvie.com/posts/a-successful-git-branching-model/
"Release branches
May branch off from: develop Must merge back into: develop and master Branch naming convention: release-*"
"Hotfix branches
May branch off from: master Must merge back into: develop and master Branch naming convention: hotfix-*"
I agree. The workflow maybe a valid scheme, but it definitely isn't Git Flow. So either incorporate the above comments into the page or remove the reference to Git Flow. But I don't think it is a valid scheme without a develop branch in the superproject. As long as their are files in the superproject and not just submodule references, you're going to need a develop branch to isolate superproject development changes from released code. I'd drop the caution about the develop branch not being provided. Regarding the naming conventions of the release and hotfix branches, I don't care which one you use, but be consistent, i.e. either: release/n.n.n hotfix/* or release-n.n.n hotfix-* Regarding the "latest" branch. Technically you really don't need it as you can checkout the develop branch and use a "git submodule foreach" to checkout the HEADs of the develop branches in the scripts. Also, any changes you make to the superproject would have to be first made in the "latest" branch and then merged into the develop branch (just more work and something to forget as most work will center around the develop branches). If you decide the "latest" branch is desirable, please change the name to something like "bleeding_edge" or "integration" (as mentioned on the web page). Folks not that familiar with git and coming from other SCM systems, e.g. Clearcase may thing that "latest" contains the latest released code. Regarding the release/n.n.n branch naming convention and tags. Normally in a X.Y.Z numbering scheme, the X.Y represents the branch and the Z is used to name the tag, e.g. tag boost-X.Y.Z on branch boost-X.Y (or in this case release/n.n). The web page mentions nothing about how/when tags are used and the naming convention for them. Also, as part of the tagging workflow I'd like to see the boost release script tag the submodules' master branches with a tag indicating the boost release, e.g. boost-X.Y.Z or whatever naming convention is picked. That way it's easy to identify what library specific release corresponds to the boost release just by looking in the submodule. Also, it makes it easier for the libraries not adopting independent releases (e.g. CMT orphaned libraries?) not to have to worry about tags. With the X.Y.Z proposed naming convention, what is the criteria for bumping each level? Something like: - Bumping the X implies a release with changes breaking backward compatibility with release X-1.Y.Z. - Bumping the Y implies a release that's backward compatible and new features. - Bumping the Z implies a release that's backward compatible with no new features (or very, very small ones). Whatever it is that should be documented somewhere. Also, will the libraries having independent releases follow the same naming convention/criteria. Having multiple versioning schemes and/or criteria for bumping each level would be confusing for the boost users. Are the release branches long-running branches or as in the Git Flow model, will be removed have the release branch is tagged and merged to master? Regarding the "Open Question". It all depends on how many previous releases Boost will support. If only the current release, then you could get away with just release. I would assume, though, that at a minimum, Boost should support the current and previous release. In that case you can do something like the Linux kernel does, have a maintenance branch. Anything more that that probably would require using the scheme you've come up with. BTW, the scheme Boost has maps fairly well to the Linux scheme (so Boost's scheme can't be too far off): maint (updates for the previous release) master=master (current release) develop=next (next release) latest=pu (proposed updates) The "Naming Rationale" link points to Boost Trac main page. Isn't the Naming Rationale what this page is about? Michael