--- Comment #18 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Alex from comment #16)
> > This issue highlights that Tomcat can always use more real-world testing
> > and I would encourage folks to download the release candidates as the votes
> > are announced and test them in their environments. The more folks that do
> > this, the more issues like this we will catch and the sooner we will catch
> > them.
> Maybe adding workaround flag in one version, changing the default behaviour
> and then dropping flag some versions later may be better in terms of
> real-world testing then logging and testing RC's as an approach for such a
> serious things?
You are presuming that there were no 9.0.x releases (beta!) which included this
change with no comments for months. In fact, it was included in 9.0.2 with
logging, then completed in 9.0.5 as Mark details in comment #14. I think this
qualifies as a reasonably-slow roll-out. There is no reason to wait many years
to change things... the alternative is an internet where it takes 20 years to
widely-deploy new encryption capabilities (TLS) and effectively NEVER to
properly-implement some IETF specifications (e.g. cookies). Sometimes you have
to just have to remove the headphone jack.
You took the big step of a 4-major-release-version jump and seem incensed that
things aren't working exactly as they had worked before. This is the purpose of
testing. In this case, you found a problem, engaged the community, and got a
fix. Instead of complaining bitterly, how about a "thanks for the 5-day
turnaround on a blocking issue I'm having"? If you wanted zero changes, you
should have stayed on the version where you were.
If you'd like to debate Tomcat's development methodologies, release cycles, or
test-coverage, you are welcome to join the dev mailing list.
You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org