Oleg wrote: > Adam, with all due respect let me point out that we have stable > HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API > and/or code stability. If GUMP cannot be configured to use any other CVS branch but > HEAD, this is a totally different kind of a problem, and it should be brought up to GUMP > folks, not to us.
Gump can be configured, but it is community configured, and your project has selected this configuration. I am (very recently) a "gump folk", although still learning -- and these opionions are most definately, my own -- however I think we are discussing "Gump ettiquette". I think your project unwittingly did something a bit unfriendly, and I'd like to cultivate a "gump how-to" or "how-to-be-a-friend-of-gump" that helps you/other projects from doing the same in the future. I care because I feel Gump supports inter-community respect, and project collaboration, and I want projects to depend upon each other more, not less. Gump's philosophy is to use CVS HEAD, and does so by default. You could've set your project to use the stable tag, but without it you involved all your dependees in any major changes. Now debatably this is a good thing, it helps you find the problems, but as your list of dependees gets long (and I hope it does :-) and if things fail, then this stops a whole sub-tree of Gump from Gumping ... and hence is detrimental to the community. As such, a separate transition project (one for stable, one for CVS HEAD) allows you and sub-projects to decide when to "test the new stuff" and you (via aliasing) can decide "when to flip the switch". As for having unit tests run in the gump project, there are three schools of thought. First says don't do them, Gump is for compiling -- unit tests cost Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them to your main project. Third says -- create a separate xxx-test project for your unit tests. The logic behind the third (which I am becoming a fan of) is that dependees can then chose to depend upon xxx or also upon xxx-test. Typically unit tests are very strict, so depending upon xxx-test might cause wasted gumping (a compile error might not be found due to some obscure unit test failing), so folks would normally not depend upon xxx-test (their yyy-test would find it) unless they felt xxx was unstable, and then they could. I think these are nuance of using Gump that escapes most Gump project configurer [I am just getting them], and I think it needs to be address via some sort of "FriendOfGump" guidelines documentation on Gump. I am copying the Gump list for their input, and if a conscensus is there I'll try to write up the documentaton. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
