Gennadiy Rozental wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:012301c7a6cc$59a39360$6407a80a@pdimov2...
My current development model is sync against CVS HEAD, do work, commit, check test results, fix. My use model is sync against CVS HEAD, compile project, yell at whoever introduced a regression in the boost component I'm using. This works well for me and I'd like to keep working in a similar way.
IMO this is not the desirable scheme in general. Actually this is exactly what we *should not* be doing IMO.
It works for me. As a Boost user, I simply don't use Boost components whose HEAD versions are unstable. As a Boost developer, if a dependency takes too much time to stabilize, I sever ties with it and reimplement the parts I need. This is rare since I have low tolerance for dependencies anyway. :-) I understand that this mindset may be unusual. Still, I find the idea that the trunk is assumed to be unstable a bit odd. The trunk should be stable and everyone should work to keep it that way.
What directory structure are you talking about?
boost/ foo/ foo.hpp bar/ bar.hpp the key point being that a library is not allowed to put anything else in boost/.
The dependency management can also be introduced at a later date. It is not as fine grained as in your proposal - you can't depend on a specific version - and this is intentional, to keep things simple.
What value does it have then? This is what we got now "informally".
The value of the dependency management is to allow subsets of Boost to be tested and released.
This step requires the test infrastructure to be updated to allow testing a specific library and only pull a subtree.
If there is no way to point to older version of my depenencies, what the poiont of subtree pulling? They all going to be the same.
The point of subtree pulling is to verify that the library can be built against its dependencies, not against the full boost/ tree as we currently do.
A release also doesn't require any new tools; it can be done manually by the release manager. We may be able to streamline it with tools in the future, of course.
Release still require all libraries to be tested together, right?
Right. The release process basically consists of integration testing.