Stefan Seefeld wrote:
<sarcasm>At this point there isn't much doubt that anything will improve things.</sarcasm>
I knew I wasn't going to get away with that. oh well.
The main problem that is addressed by this proposal is that testing tests "one thing" at a time to "one" person, so when something fails its easy to isolate without everyone looking at all the code. It also elminates the requirement that everyone be in sync with their next release simultaneously. This is obviously not scalable and the source of much agony in the past.
And this is still the part I'm not understanding. If there is one 'stable' branch, and if that's the only reference point, this is IMO a scalability problem.
Contrast that to the much more radical proposition to make boost modular, where each 'component' (or however you'd like to call those) would follow its own release schedule, and a developer can choose which versions of prerequisite components to depend on, as long as they are actually released.
I'll make the contrast. The second is a more elaborate version of the first. More elaborate than necessary in my opinion. But we can start with the first right now by just adopting practices in common usage. It is common to have a "stable" trunk and develope on a branch, test the branch and merge into the release version. BTW its already being done now by some developers. I'm doing it, Beman is doing it Joaquin is doing it (witness that he has been able to provide an increment to to multi-index). I'm convinced that little by little more developers will migrate to this model. If in the future, its necessary to make this even more elaborate that can be considered later. Robert Ramey