You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by rahul <Ra...@Sun.COM> on 2007/11/20 21:23:03 UTC

mod_jk compatibilities between versions.

Hi,
    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)

ie 
Is JK-1.2.25 going to be completely compatible with JK-1.2.26

How about JK-1.2.25 and JK-1.3.xx and 

JK-1.2.25 and JK-2.xx.yy 

which is the version change where I can expect the compatibility to be
guaranteed?


                                    rahul
--
1. e4 _

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: mod_jk compatibilities between versions.

Posted by Rainer Jung <ra...@kippdata.de>.
rahul wrote:
> | 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?.

Any version in the 1.2.x line will be compatible in the sense, that 
configs working for older versions will work at least as well for newer 
versions. There have been very few exceptions, e.g. we sometime 
introduced a new feature in some 1.2.x release and immediately observed 
a problem with it's semantics, so we needed to change it in 1.2.(x+1). 
Another example was, when we started to enhance the status worker a lot, 
we broke the URL structure (query argument names). But we really try 
hard to stay compatible in the 1.2.x line. If a feature is completely 
new in 1.2.x, there is some risk, that we need to make a change to it 
soon after the first release of it. We don't expect a lot of new 
features for the existing mod_jk, it's pretty stable now.

The only other existing major jk version is mod_jk2, which is 
incompatible from a configuration point of view and deprecated. Although 
that project started later then mod_jk, it is no more alive and all 
important features of mod_jk2 have been backported to mod_jk.

We have a plan to start a JK3. This again will be incompatible with 
mod_jk and mod_jk2, but work didn't really start until now, so a first 
release is still far away.

There is no mod_jk 1.3 or similar, and there are no plans for it.

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: mod_jk compatibilities between versions.

Posted by rahul <Ra...@Sun.COM>.
| 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: mod_jk compatibilities between versions.

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rahul,

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

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.

> JK-1.2.25 and JK-2.xx.yy 

Same here: there are no 2.x 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).

On the other hand, they all implement the AJP12 and AJP13 protocols. So,
in a sense, they are all entirely compatible (with each other).

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.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQ8zY9CaO5/Lv0PARAvnxAKC1wJEKvRb7Ox0DBJrXSx38Z4oawQCeNU1O
B7+7v7hcCb010YHrG1Fokug=
=CM1Z
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org