On 12/25/2012 5:32 PM, Robert Ramey wrote:
Daniel Pfeifer wrote:
2012/12/25 Rene Rivera <grafikrobot@gmail.com>
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