"Peter Dimov" <pdimov@mmltd.net> wrote in message news:018901c7a6d9$6d1e8820$6407a80a@pdimov2...
Gennadiy Rozental wrote:
"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.
Almost; the user is typically interested in a version that works and contains the libraries s/he needs. A suitable release may not exist (yet).
This is the way things are now. In a future we hopefully make boost releases more frequent and users don't have to go into undesirable territory of unreleases libraries.
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.
In this case I'll fix these libraries myself.
Well, you maybe the one who can easily fix any boost library one uses. An "average" boost developer (me including) can't in general. There is also a huge problem with two developers making independent changes to the same component.
And this is not a good practive in general IMO. Since you are causing breakage to "single definition rule" on library level.
There is no observable downside to this conceptual breakage, whereas the breakage resulting from a failed dependency is quite visible.
There are quite observable downsides: * You may cause ODR violation to anyone who is using both yours and dependant library. * Your code most probably is not tested * You are requires to maintain this code now, inncluding porting on new compilers. * Users might be confised. The see class Foo used in your code. They expect it to be from library libFoo. But thre libFoo docs mention different interfaces. libFoo developer now have t ofigure out where this discrepency comes from. and so on.
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?
You make an incremental change, test it locally, then commit to trunk?
I don't care about local testing for this discussion. I do my testing on one compiler I have access to. Now I need to test agains 30 other configurations. It may take me month or two to clear up all the problems.
I didn't mean "stable" as in "guaranteed to pass all tests", more like as "stable enough for practical use".
This is one of those "grey" terms I believe we have to avoid as a plague. Every one have different understanding what "stable enough" means. We need formal definitions that do not leave a space for doubt. Last release version of boost is stable. No one ever going to make any changes to it to disrupt my testing. And until I am realy to test against new version of dependancies I would stick with it. Then I can add them one by one.
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?
Large commits are always a problem. My suggestion is that we should simply avoid large commits. If the incremental steps towards the goal are visible
How do you invision this to happend ;)) With 100+ developers working simultaniously around the world. Will I have to get a ticket to commit my changes?
in the trunk, they can be tested and the problems can be fixed as they appear, rather than as one large batch at the end of the day.
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.
As I understand it there are technical problems with svn:externals that make the above not work as well as it could. But it's possible.
The problem is technical, meaning it should be easiest for us to fix ;)
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)
You can compose a release by using a specific library version. It should be possible to use the version from the last release as a starting point.
I can compose whatever I wont. How will I test it?
I still don't see the difference. What do you win by pullig npart of the tree?
Test failures if a library #includes "boost/foo/something.hpp" without foo being listed as a dependency. Without this check, dependencies tend to find their way into your library while you're asleep. :-)
This is achieved in my solution diferrent (easier IMO) way. If library A is missing from library B dependency list, the A/<version>/boost is not added to the list of includes and B fails to compile. This is the safest possible solution, don't you think?
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?
I see nothing incorrect per se in your proposal; it's quite good. But how do we get there from here? How many extra tools do we need? Can we implement it in small steps?
I don't believe we need any extra tools. We potencionally need to make a change in make system to support explicit dependency specification. And we need to change release packaging script to select components that are ready for release. For example, in comparison with Beman proposal it doesn't require any scripts/human efforts to maintain stable branch.