"Emil Dotchevski" <emildotchevski@hotmail.com> wrote in message news:BAY110-DAV9D1AAB78C539607616C5ED4210@phx.gbl...
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.
There are really only two possibilities:
1) fix the GUI lib, or
2) sever ties with it, reimplement the parts you need, and explain in the documentation how a GUI lib can be hooked by the user.
or use older version of GUI library that you know works.
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 trunk is not stable, what motivation do you have for testing your code?
I don't care about trunk in general at all. I don't believe we need a notion of boost trunk whatsoever. I've got trunk version of my library I need to test. And my library depends on particular versions (possible truck) of other components.
If I am done with my development when can I put it into "stable" trunk?
As soon as you're reasonably sure that it wont break anything.
How can I be "reasonably sure" (yet another "grey" term) until I run the tests. And to run the tests I need to commit the changes. This is chicken and egg problem.
What if I break something?
Then you have everyone screaming, and you hope that you can do a quick fix before someone reverts your changes to make the trunk stable again.
What If I am working on port for new compiler? I don't want anyone to test agains my trunk version until I am done. And it may take me month (beasue I went on vacation right in a middle;0)
What if N libraries merged their changes the same time.
This is not possible, changes are atomic.
Within an our? Some cozy satuday evening ....
How long will it take t osort it out?
It'll certainly take less time to sort out compared to if the trunk is unstable (and everyone is more tolerant to bad commits.)
*Why* anyone but me should care about my bad commit? In reliable system no one should. Gennadiy