Re: [boost] [1.48.0] Proposed Release Schedule

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 
> include
> managing)... Of course I'm only talking about the current Boost file
> structure.

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
version.

In order to implement this for the testers, something equivalent to the 
following would
be necessary.

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
> testers.

Robert Ramey