On Mon, Dec 17, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Dec 17 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
I would like to re-iterate the idea that trunk and release libraries be tested against the next release (ie the current release branch).
Problems with the way your idea is expressed:
0. I'm not sure you mean "release branch" as defined by gitflow, which defines our branching policy. You might want to take a look at that.
1. In the gitflow model, "release branches" are temporary. You need to decide what to test against when there's no release branch.
2. "The current release branch" is not specific enough. Each individual library *and* the Boost super-project can all have release branches, and they almost certain do not correspond to one another. The Boost super-project should release combinations of states on the "master" branches of individual libraries.
Robert Ramey
PS - On personal machine, I have the release branch loaded and just switched to the trunk for the serialization library. This has made my life much easier since I've avoid the above problems.
PPS - Hmmm - I wonder if this will be possible/easy under the Git system.
The model described in the PS is possible/easy. The idea quoted at the top is still not clear enough to say anything about.
I think perhaps Robert may be using current subversion branch naming, so in the GitFlow model what he is talking about testing against is "master". Until enough time passes to be reasonably sure everyone has switched to the GitFlow branch naming, every time someone refers to "release branch" without being more specific, we really have to ask them if they are talking about the old svn branches/release (i.e. they should have called it "master" if talking about modular Boost) or the GitFlow temporary (and often private) release staging branches that do not represent the latest actual release? --Beman