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