On Tue, Feb 1, 2011 at 8:57 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 2/1/2011 7:21 PM, Dave Abrahams wrote:
At Tue, 01 Feb 2011 10:12:45 -0600, Rene Rivera wrote:
That is, I don't think we can live without full trunk testing.
I'm curious why not. I'm fairly sure I don't want any resources wasted on it for my libraries.
Because in the three testing scenarios I mentioned it would be the only one to give you fully integrated testing without being in the release.
What does "fully integrated testing" mean, though [I mean that in two senses: 1. what's your definition, and 2. rhetorically, does it have any meaning]? You're not testing against any past or future released state of other libraries. Someone could have checked in minimal changes to the release branch and be off exploring some grand rewrite on trunk for which there's no intention that it be in the next release.
Of course a full dependency integrated testing of an individual lib with a release base could be a substitute for full trunk testing. But for some components full dependency integrated testing might devolve back to close to full trunk testing. But again, this all depends on how close or far future procedures are to the current ones.
Sorry, I guess you lost me. Here's what I want: Each change I make is tested against the previous released state of the rest of Boost (so I'm not trying to manage a moving target), unless otherwise specified. I might specify otherwise if my new work depends on an upcoming-but-not-yet-released version of another library, for example. I think Boost release managers would want the latest releasable state of all libraries tested against one another, unless otherwise specified. In today's world that corresponds to testing the release branch. Whenever that is "all green," they can spin the release. They might specify otherwise, for example, if they had to roll back to an earlier released or releasable state of one of the libraries. -- Dave Abrahams BoostPro Computing http://www.boostpro.com