Re: [boost] Request for comments on super-project workflow doc

Subject: Re: [boost] Request for comments on super-project workflow doc
From: Cox, Michael (mhcox_at_[hidden])
Date: 2014-01-03 03:25:04

On Thu, Jan 2, 2014 at 3:47 PM, Peter Dimov <lists_at_[hidden]> wrote:

> 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