"Peter Dimov" <pdimov@mmltd.net> wrote in message news:016b01c7a6d2$7722c9a0$6407a80a@pdimov2...
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.
An "average" Boost user is primarily interrested in latest released version.
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. :-)
What if you depend on serialization or GUI lib or XML parser. It might not be possible to "reimplement" all your dependencies. And this is not a good practive in general IMO. Since you are causing breakage to "single definition rule" on library level.
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.
If trunk is stable, how do I test my development? If I am done with my development when can I put it into "stable" trunk? What if I break something? What if N libraries merged their changes the same time. How long will it take t osort it out?
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/.
That's good goal. I support it. But this tree could exist as a reflection of actual tree (using svn externals): boost/ foo/ -> foo/truck/boost/foo foo.hpp -> foo/truck/boost/foo.hpp bar/ -> foo/truck/boost/bar bar.hpp -> foo/truck/boost/bar.hpp How run svn update in this directory and you pull all you need.
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.
How can I release and test my subset if I can't compile with truck version of library I depend on. I don't really care about latest changes? I would be happy to work with last stable version (last boost release)
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.
I still don't see the difference. What do you win by pullig npart of the tree? Disk space? Every time you put you get the same files. Just different subsets.
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.
And this is what we should be avoiding. There should not be testing stage during release. Let's take a look on this from different prospective: what in my proposal you find incorrect? What are the problems for you personally if we do this? Can you list all? Gennadiy