Re: [boost] [Git] Regression testing modular Boost

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-12-26 09:50:20

On 12/25/2012 5:32 PM, Robert Ramey wrote:
> Daniel Pfeifer wrote:
>> 2012/12/25 Rene Rivera <grafikrobot_at_[hidden]>
>>
>>> On 12/17/2012 12:25 PM, Dave Abrahams wrote:
>>>
>>> I don't know what you mean by "real modularity".
>>
>>
>> Monolithic development (currently): There is one repository, one
>> release cycle.
>
>> Modularized development (proposed): Each module has its own
>> repository and release cycle.
>
> This would suggest that each library have it's own versioning sequence.
>
> This in turn would suggest that each library have a list of dependcies.
> Each entry in this list would be the the pre-requisite library along with
> the minimum version number required.

It would also suggest that each library is *only* tested against those 
requirements. And that any other combination is not officially supported 
when it reaches the end users.

>> But the testers *must* test what Boost delivers as a package. At some
>> point end users get a Boost installed. And that's what we have to test. If
>> we don't test that we will have unknown issues to deal with.
>
> Hmmm - I would say at some point the package to be deployed by the
> boost organization should be tested.  This should mean that each library
> is tested against all the other libraries in the package.

Yes, that's what I'm saying.

> But for developers and "testers" there is no reason to require that
> the be testing the whole of boost. If a particular library is tested against
> the current (or next) release deployment, that should be enough.

For developers perhaps that enough. But not for testers. At some point 
someone has to test what is released. And the sooner that happens in the 
release cycle the better. Currently that testing happens continuously, 
in the form of the release branch testing. Which is ideal since you 
can't get any earlier. For github it means testing will happen on the 
master branch of the super-project and the sub-projects as a monolithic 
package. Along with this there's also the question of putting the 
release archive together. Seeing that if we had a working script that 
put the release archive together from the master branches it could be 
possibly be adapted to work for testing.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail