Subject: Re: [boost] [1.48.0] Proposed Release Schedule
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-07-15 13:46:33
Rene Rivera wrote:
> On 7/13/2011 11:32 AM, Robert Ramey wrote:
>> Also, I'm (again) offering the suggestion that the periodic testing
>> be altered so that a library X on the trunk is tested againts the
>> current state of the libraries on the release branch (that is the
>> NEXT release).
> I'm all for that model of testing. But..
>> I believe this would have a number of benefits - including the
>> streamlining of the release process. It would also speed up the
>> testing itself since the release branch changes less frequently so
>> there would be fewer dependencies for each test.
> Hm, I'm not sure that's true. It's certainly true if you are isolating
> the testing for each library and doing each incrementally.
I think that's what I'm advocating.
> But that's a lot of Boost checkouts to maintain (or some complicated
> managing)... Of course I'm only talking about the current Boost file
And this is the rub. On my own personal system it's not a problem
of course since I have have a complete copy of the release branch on my
system - EXCEPT that for the serialization library I have the trunk
In order to implement this for the testers, something equivalent to the
For each library X which has changed on the trunk
Rename library X directories on "release" to "previous release"
Rename library X trunk directories to release
Run bjam tests
Reverse steps 2 and 1 above.
I'm not specifically advocating this as an an implementation method -
I'm just describing a logically correct method of what I would like to see.
The SVN system does have a "switch" comand from changing directories
in one's local tree - but it merges (not what I want) and it takes forever.
Maybe GIT users want to chime in here - this might be just the incentive
to get "over the hump" in convincing those of luddites who hate messing
with our tools to get on board the GIT bandwagon.
>> This would require a change
>> in the testing scripts - but not a huge one.
> I certainly welcome patches to make this possible, and reasonable for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk