Archiving it here. From: Brian Rectanus Subject: Re: [> Re: [webstack-discuss] Apache External Modules ARC (DRAFT)] On Nov 20, 2007 11:15 AM, rahul <rahul at sun.com> wrote: > rahul wrote: > > mod_jk, mod_fcgid and mod_security have a single active > > release. (There was a module named mod_jk2 which was > > deprecated. It was not the successor to mod_jk.) > > Aside from whether the components have more than one active release > branch, the interesting question is how compatible they are from one > release to the next. As an example, if this case provides > mod_security2 2.1.3, what's the chance 2.1.z (z > 3) will be fully > compatible? What about a 2.y.z (y > 1)? > > While there's no absolute answer to these (without predicting the > future), it's good to document each component communities expectations > since that will guide what the future update options might be and it > also determines whether 'Uncommitted' is correct for each given set of > interfaces.
I guess there are two flavors of 'compatible' here. Compatible with Apache httpd versions and compatible with previous versions of itself. For mod_security 2.y.z I need it to be compatible with all Apache httpd 2.a.b. Now, there are some exceptions to some older 2.0.x releases that had bugs (some versions prior to mod-security being available on httpd 2.x), but I try to make sure mod_security 2.x is always working with the next httpd release prior to it being released (if it is not, then I'll get a mod_security release out before the httpd release). For example I will be testing 2.1.3 (soon to be 2.1.4) against httpd 2.2.7 before its release, etc. Also, I keep the mod_security trunk compatible with the httpd trunk. In all cases, I want to have mod_security running against all httpd releases where possible (even it I have to add code to work around certain httpd releases). As for compatible with itself, that is tricky to answer. Newer mod_security builds should be able to handle older configurations for the same major number 2.y.z, but there will be additions in later releases that are not valid in earlier configs (as well as deprecated features, etc). With the 2.5.x releases I am working on a feature to allow for checking the version for doing sort of a if modsecversion >= 2.1.5 then ... endif in the config, so this is less of a worry. However, newer versions may subtly change how a feature works so the same rule may not work exactly like it used to, but it should not fail to load. Since mod_security is all about user defined rules this could be a potential issue, but probably outside anyone's control as it has to do with the intended usage of the rules vs the module itself being broken. Now, as noted, I cannot predict the future, but my best effort goes into this and I am committed to making sure any issues are promptly fixed. And I get paid for this, so I have good incentive ;) This message posted from opensolaris.org
