| rahul wrote: | > I am trying to integrate mod_jk with the apache 2.2 package | > distribution in solaris. | > I would like to know what would be the versions that can have | > incompatibilities with the previous versions (both API and configuration)
| Check the change log: | http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html thanks I will check it. | It contains all changes between each version. If you need to know what | changed between 1.2.14 and 1.2.25, then you need read all of the changes | for intervening versions. | | > Is JK-1.2.25 going to be completely compatible with JK-1.2.26 | | All of the 1.2.x versions are compatible with each other. | | > How about JK-1.2.25 and JK-1.3.xx and | | I don't believe there are any 1.3.x versions. I had meant it for the future versions. ie. at what version level change can I expect the compatibility to get broken (If there is a reason for breaking it). To ask in a different way, If you find that you need to break the compatibility between releases, which version number will you increment?. | > JK-1.2.25 and JK-2.xx.yy | | Same here: there are no 2.x versions. (As above. I meant the future versions) | > which is the version change where I can expect the compatibility to be | > guaranteed? | | Do you mean "feature compatibility"? Each version of mod_jk includes | improvements and features that were not included in previous versions. | So, in a sense, all versions are incompatible (with each other). No, I meant the newer versions to not break any thing if dropped in place of older ones. | On the other hand, they all implement the AJP12 and AJP13 protocols. So, | in a sense, they are all entirely compatible (with each other). See above. If there is a chance that you want to break drop-in compatibility for some reason, which is the version number that will change. (Not that it has happened yet. But _in case_ ) | All versions along the 1.2.x line are expected to be drop-in replaceable | for other versions in the same line. You should always read the release | notes between versions so that some fixed bug doesn't end up breaking | your setup. The reason I had asked is that if we know for sure that a version would be drop-in replacement, we can push it as an inplace upgrade. While a version that may break compatibility should be placed in a separate location or given a separate name when upgrading so that nothing gets broken. rahul -- 1. e4 _ --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
