Boost logo

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk