On 01/02/2014 02:58 PM, Peter Dimov wrote:

Peter A. Bigot wrote:

...

* Branch "latest": automatically tracks "develop" of submodules (scripted). ... Does anybody have a use case for this?

Yes.

This branch is the equivalent of the old SVN trunk. It enables testing of the develop branches of the submodules. The typical Boost developer workflow is:

- make changes - run local tests - when those pass, commit to develop (SVN trunk) - wait a few days for the develop (SVN trunk) testers to cycle - when those pass, merge to master (SVN release)

In addition, testing a composition of the develop branches of the submodules enables people to detect inadvertent breaking changes in a dependent submodule and complain loudly. This ideally happens before the merge to master. (Or, alternatively, if the changes were in fact deliberate, it enables them to fix their code ahead of the merge to master.)

Ack. FWIW, that's not how I see submodule-based git projects in the general case. If most Boost modules are independent (are they?), this process appears to introduce unnecessary coupling, rather like testing a bunch of unrelated feature branches together instead of validating and merging them one at a time as their individual developers feel they're ready. I suspect that separate curated develop and auto-updated latest/master (latest/develop) would be more robust. E.g. that approach reduces the risk of refactoring the assert library: neither module would appear in the stable branch (develop, in my proposal) until a release manager confirms they're compatible, preventing the churn from impacting people who don't care where the capability is placed. But as long as everybody who maintains a Boost module is clear on the expectations and process, the assumptions of non-Boost people aren't particularly relevant.

...

Boost imposes no stability requirements on submodule develop branches, let alone interoperability requirements.

That's not - quite - true. The develop branches are expected to work, even though this is not strictly enforced. We mostly rely on the honor system. :-)

OK. Somebody should update https://svn.boost.org/trac/boost/wiki/StartModWorkflow?version=9#Branchnames then, since no stability expectation is mentioned. In its current form, I would expect to feel free to initiate a long-term refactoring on my develop branch with no plans to push to master or maintain compatibility with other modules for several super-project release cycles, a process more consistent with my expectations of what the module master and develop branches mean under git-flow. Peter

Peter A. Bigot wrote:

Ack. FWIW, that's not how I see submodule-based git projects in the general case. If most Boost modules are independent (are they?),

No. I'd say that the probability for two randomly selected submodules to be independent is not above 50% (although I haven't actually done the math). Boost libraries tend to depend heavily on other Boost libraries.

this process appears to introduce unnecessary coupling,

I don't see why. If the libraries were indeed independent, testing them together would not couple them to one another.

rather like testing a bunch of unrelated feature branches together instead of validating and merging them one at a time as their individual developers feel they're ready.

The suggested arrangement is partly shaped by what we had before - it's a gradual transition. And what we had was that testers checked out an SVN branch and ran the tests on that. (All of Boost was in one SVN repository.) So now, under the new arrangement, the testers would just check out the "latest" branch of the superproject - which would check out the "develop" branches of the submodules - and this'd be exactly equivalent to the old "trunk" test run. I agree that if you start from scratch, you might be able to come up with something better. But I'm not sure that it will be that different. You have to test the "develop" branch of a submodule; submodules generally depend on the rest of Boost; hence, you need to check out the rest of Boost somehow to create the environment in which to test the submodule. So the two obvious options are either to test submodule:develop against world:master, or to test submodule:develop against world:develop. The latter has the advantages that (a) it is what we've done for years and (b) it's easy to achieve without changes to the test scripts, by using a "latest" branch.

I don't want to waste anybody's time (including my own) pro-actively documenting the exact details of what I did, though I may clean up the tool and submit it for incorporation into some existing module if

Peter A. Bigot wrote: there's strong interest. I think that a tool that - at least - outputs the dependencies of a given submodule will be highly useful. If we are serious about modularization and cutting dependencies, we'll certainly need something similar. It's possible that the existing "bcp" tool already can do this though; I'm not sure.

On Thu, Jan 2, 2014 at 3:47 PM, Peter Dimov 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

On 01/03/2014 06:23 AM, Daniel James wrote:

On 3 January 2014 08:25, Cox, Michael wrote:

...

latest=pu (proposed updates) I'd rather avoid such an unfortunate acronym. Or is it a deliberate comment on quality?

It can be, but I don't think he was proposing using those names, just stating that Boost is not diverging wildly from the traditional git work-flow: * master: validated stable; evolving release branch; permanent * next: accepted for stable; never rebased but might still require fixes before being released * pu: appears to have value, so let's try it in place, but if it doesn't work it gets yanked through a rebase Some of us still follow this much simpler model for repositories where it's appropriate. It served Linux for a long time, and is still the flow used for git itself. It is not appropriate for Boost, though it might be appropriate for submodules if next is renamed develop. Peter