Niclas Hedhman wrote:
If we have made a prior commitment of keeping the 2.1.x compatible with
JDK1.3, then that should stand. It should not be a matter of what a handful
developers think. They are usually on the curring edge anyway, but what the
user community are depending on. It is these type of inconcistencies that
drives users away from a project, and by now Cocoon I feel Cocoon has a
rather low reputation and considered a niche and novel project that one can't
use in 'real' projects.
If we find it hard to maintain, then let that be it and stop evolving it.
Saying that we keep evolving 2.1.11+ in JDK1.4 (assumingly backporting stuff
from 2.2.x) and on top of that maintain a 2.1.10.x line for bug fixes seems
even more work to me.
I would be voting -1 in behalf of unheard users.
Niclas,
Thanks for bringing this up. I'm just surprised it wasn't raised
earlier. I just took a look at
http://cocoon.apache.org/versioning.html. Removing support for JDK 1.3
on 2.1.x seems to violate that document as all patch levels should be
binary compatible. So it seems the only way to remove support for JDK
1.3 would be to move to a new minor version number.
Again, it would also seem to me that the current 2.2 also doesn't
conform to that document as the change from 2.1 to 2.2 seems to me to
something more than minor given how much the core has changed. A change
from 2.1 to 2.2 would imply that nearly all user written components will
still work perhaps only requiring a recompile. While this may or may
not be true - I certainly haven't tried - it is certain that how an end
user application is integrated with Cocoon has completely changed. I'm
also not sure how many existing sitemaps will require modification. So
I would think trunk should be released as 3.0, if for no other reason
than allow the next 2.1 release to be 2.2.0 without jdk 1.3 support.
Ralph
