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/