Boost logo

Boost :

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-12-16 14:12:11


Peter Dimov wrote:

> I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?

I think I can answer this one, if I rely directly on the GitFlow
branching model [1]. It would be great if somebody from the
modularisation team could check my answer and my line of reasoning.

The master branch will not need to be tested frequently, because it
will only contain final release versions. In fact there will probably
be a policy that you may only merge into master when the candidate
release version of your library has already been verified to pass all
unit tests. Only prior to a global Boost release the master branch of
the superproject will be tested, and if any subprojects turn out to
conflict this will call for some hotfixes on the respective
subprojects.

So frequent, regular testing will only take place on the develop
branch.

When a library is heading for a new release version it will fork a
temporary release branch from develop. The primary purpose of that
branch is to remove all remaining errors, before merging into master
as well as back into develop (the library version in the release
branch is the candidate release version that I mentioned above).
Obviously that branch will have to be tested as well; or perhaps
temporarily *instead of* the develop branch. I don't know whether
there will be infrastructure that detects the presence of release
branches automatically (this should be possible if all subprojects
adopt a common prefix for release branches), or library developers
will have to request that their release branches be tested.

An alternative plan could be to have the testing team /only/ do the
automatically detected release branches and the pre-global-release
testing on the master branch, and make testing on the develop branch
purely the responsibility of the library maintainer. This would
relieve the burden on the testing team but might present library
maintainers with unanticipated problems when they fork a release
branch. In order to compensate for the latter, there could be an opt-
in policy where library maintainers may request test runs on any
specific branches of their choice.

The latter procedure is probably the most convenient for all parties
involved, but might als be the most challenging to realise.

HTH,
-Julian

_____

[1] http://nvie.com/posts/a-successful-git-branching-model/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk