on Wed Feb 08 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 8 February 2012 14:37, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
This might have been mentioned before, but gitflow seems to be ideal. See [5] for an explanation of the branching model and [6] for an optional tool which automates workflows that adopt the model.
The problem that we face with something like gitflow is testing. We only have the infrastructure for testing two branches so we can't adequately test feature branches. We really do need to test on a wide variety of platforms as early as possible.
The way we plan to handle this with Ryppl is that you check in a testing specification with your project. The testing specification is just a text file, something like this JSON: { <configname>: { dependencies: { /* dependency versions */ <libname>: <git tree-ish>, ... }, cmake: { /* properties passed to cmake */ <key>: <value>, ... }, platforms: [ <platform-string>, ... ] }, ... } Where you can request multiple configurations to be tested for commits on each branch. To get your in-development work tested, just publish a feature branch containing a test specification file to your public repository. The test results are then added to the commit using git notes.
But we wouldn't want to merge half done features into the develop branch just to get testing (this is one of the biggest problems we have at the moment, changes are often in trunk for some time before they're merged into release, if at all).
A possible solution would be to use the 'develop' branch as the equivalent of our current release branch
I take for granted that we're going to have a modularized boost with a separate repository for each library (<https://github.com/boost-lib>) and each library will have its own develop branch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com