On Thu, Apr 25, 2002 at 08:31:14AM -0000, [EMAIL PROTECTED] wrote: > dirkx 02/04/25 01:31:14 > > Modified: support ab.c > Log: > During the 1.3->2.0 migragrion; ab its #defined VERSION own string was replaced > by that of the base server distribution it sits in. Propably by accident. > > This is propably not a good idea - as ideally one would like to be able to compare > ab runs as much as possible - even across releases of apache 2.0 - assuming ab or > the dependent APR has not changed (note to self: we do not track APR in our version > structure). This commit decouples the version strings for now. Though the actual > value may be nicely confusing.
If ab has a different versioning system than everything else in our tree, then, I believe we should consider removing it from httpd-2.0 - perhaps into httpd-test. If it is in the httpd-2.0 tree, then I think it should follow the versioning conventions of the rest of the code (i.e. what was there before this commit minus the RCS ID). We recently changed mod_ssl to mimic httpd-2.0's version rather than report an unrelated version. This should help us with any bug reports. If ab 2.0.36-dev2 were included in 2.0.36, 2.0.37, and 2.0.38, we have no idea where it came from. By linking the version to the httpd it was bundled with, it gives us (IMHO) an idea of when it was compiled. As we do with any -dev version of httpd, we do not trust any bug reports on -dev suffix builds. If ab's version has a -dev suffix, we shouldn't trust its results. Having it separated out like you have just changed it to is going to cause lots of problems for us maintaining it. While your suggestion to bump the version number of ab whenever a change is made to APR that might effect ab is a nice sentiment, it isn't realistic, IMHO. There are lots of unintended side effects - if I optimize the select() call in APR for incomplete writes (something that has been occurring recently, but isn't complete on all platforms I believe), do I now need to bump ab.c's version? Like our MMN, what if I make a mistake? Or, what if the bump isn't needed on every platform? We obviously wouldn't be bumping APR's version on such a fix. (Let's not even think about compiling the same version of APR but with threads and without thread safety.) By linking ab's version to its bundled httpd's version (which implies its APR version), we have gained knowledge of its surrounding environment. I believe that is a far better situation than trying to manage ab's version independently. I believe long-term comparisons can only be done with the same test-tool binary. If you attempt to take results generated from two different binaries (esp. ones with different maturity levels in its support libraries or with different machines) and compare their results, you may have invalidated your test. -- justin
