On Fri, 7 Sep 2001, GOMEZ Henri wrote:
> Don't forget that many of us must evaluate
> a KNOWN Apache 2.0 in real environnement.
> The most known are Apache sites which use the released
> version 2.0.24 :)
>
> We could do that a each release (2.0.24/2.0.25) but
> not in real-time ;)
Probably the correct solution is somewhere in the middle. I agree with
Henri that using the HEAD is extremely difficult for both developers and
potential users who want to help testing or just evaluate 2.0+jk. However
sticking with an old snapshot and not testing with the HEAD is also bad.
Having more frequent 'stable' snapshots of 2.0 would be IMHO the best
solution, and keeping jk in sync with the latest snapshot wouldn't be that
difficult. At least we could get reproductible behavior - and more
determinism.
So my proposal for jk would be to use snapshots - regardless of alpha or
beta status. When the dust settles on a 2.0 change and a new alpha/beta
snapshot is released - we can update our APIs.
BTW, giving the amount of change in 2.0 - what about removing the 2.0 jk
connector from 3.3, and relying on j-t-c for a 2.0 connector ?
Right now the jk code in jakarta-tomcat is supposed to be 'stable', and
only clear bug fixes are ported back. The 2.0 module can't be considered
stable ( since it changes all the time ) - and what could be released with
3.3 will be certainly out of sync the next day.
Should we call a vote on this ?
Costin
