Subject: Re: [boost] [Git] Regression testing modular Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-12-25 18:32:20
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.
> Optional: Multiple release cycles may be synced. Multiple modules may
> be delivered as one package.
> Is there room for misunderstanding? Maybe it is unclear what Boost's
> future development/test/release process will be like. But the meaning
> of "real modularity" should be clear, no?
lol - maybe - but I think we'll see otherwise. FWIW I agree with
your concept of "real modularity" - but that would be a big step for
us and we're not currently prepared for this.
> 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.
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.
> Absolutely! Boost should continue to provide monolithic packages. And
> these packages need to be tested.
> What we want to modularize is the development. Not the package that we
> provide to end users.
If each library has been tested against the release, there is no reason that
the deployment need be complete. Anyone could deploy a subset if
they wanted. We even have BCP to help that along.
> However, if we want to provide a monolithic release from modularized
> sources, we can not simply "not modularize the release". We need to
> "put it back together" instead.
Eventually, we'll get to the concept of a "deployment" package which
would be a subset of the current release versions of the libraries.