At 11:27 PM 2/26/2003, Greg Stein wrote: >* further, it states that versions differing only in the PATCH number should > be completely interchangeable -- only bug fixes. no application should see > any behavior change, other than to see a reduction in bugs > >Thus, if you write the application to require a specific PATCH level, then >you're defeating the intended policy. Doable, of course, but not nice :-)
No, not really, because.. >I guess the app could say, "hey. there was a bug fix in patch level 3 that I >must have; I'll refuse to operate with anything earlier." So it is probably >okay to have harder checks; I would just hope that we don't force apps into >that situation. Or that apps can find workarounds or degraded functionality. >(thus giving great flexibility at install time) This is very close to what Stas is saying - he has a workaround for the 'broken' flavor of apr_uri_unparse, but only plans to apply the workaround when it's required. We might have to back up one bit here ... mod_perl will probably always be bound to specific apr/apache subversions at the time it's built (or maybe with enough magic, at runtime) because it exposes our newest fn's as soon as they become available on the -dev work branch. They will always be 'deep into the guts' of the API. However, to Stas; you might consider requiring that the user upgrades their APR to something respectable at some point. Remember that pre-1.0 libs are all development/pre-release, and it might be easier to request that your users grab the 0.9.2 release or later version. Even httpd 2.0.40 should still build just fine against APR 0.9.2. Bill
