Pier Fumagalli wrote: > "jean-frederic clere" <[EMAIL PROTECTED]> wrote: > > >>>That still doesn't change the fact that whatever is in JK for versioning is >>>utterly complicated, is completely different from what the Apache folks have >>>done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at >>>a manual on how to interpret the va_version.h header every time I have to >>>roll a release, right? >> >>This version handling is like the Linux Kernel version... (but there it is in >>the first lines of the main Makefile). > > > That's not the best example of code beauty...
May be not. But a Kernel needs more complexity than a TC connector. > > >>The idea behind the complexity is that we could decide version of protocol >>based on the version containted in version.h file. > > > Get real, we have ONE protocol. And it is possible to add a #define PROTOCOL_NUMBER n where n increases when we change the protocol. (More easy than testing a version). > > > >>>Punky, your ORIGINAL file from December last year looked _MUCH_ better.... >>> >>>I'm still -1 on the version currently in CVS. This is how I would like to >>>see things at the end, exactly like Apache 1.3 and 2.0 are doing... >> >>In this case we should both mod_webapp and mod_jk/mod_jk2 version. > > > I'm not -1ing anything on JK... That code might NEED that complicateness, > and frankly I could care less.. I'm absolutely -1 on that where it concerns > me, namedly, mod_webapp... Ok... Please commit your changes. We could add the complexity when needed. > > Pier > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
