Hi Jyri, | > 5.1. Interface Stability | > | > 5.1.1 mod_jk | > The mod_jk developers will try to keep the releases of 1.2.X | > line compatible with each other. But this is not guaranteed in | > case of new features that may need to be retracted due to some | > bugs or vulnerabilities. | | So do you feel mod_jk Uncommitted is correct given the above?
what do you suggest? Do you think it should be volatile? | To review, Uncommitted means it'll stay compatible during a given | minor release: | http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ | | In other words, when a Solaris 11 (or equivalent) containing these | modules goes out, the interfaces of the module will be compatible for | the life of Solaris 11. | | If a future mod_jk 1.2.x ends up being incompatible, it won't be | appropriate to update anymore, so if there are critical bug fixes | you'll have to fork and maintain a compatible version locally. Never fun. | > 5.1.2 mod_security | > The mod_security developers will keep the compatibility | > between releases of the same major number. (ie 2.y.z with 2 being | > the major number.) But there is no guarantee that meaning of a | > rule set (configuration directive) would be exactly the same | > across any two releases. | | In the last sentence do you mean "across any two [major] releases"? | i.e. no guarantee that 3.* is compatible with 2.*? That's reasonable. yes. rahul -- 1. e4 _
