William A. Rowe, Jr. wrote:
George Sexton wrote:
I guess I'm not understanding how you use the term regression. 5.5.25
for sure did not have this problem.
5.5.26 introduced it, and 5.5.27 has it.
How do you mean regression?
x.y.-1 was free of it and x.y.-0 demonstrated it.
This is x.y.-2 is free of it, x.y.-1 demonstrated it, and x.y.-0 still
has it. From the perspective of a release manager, this is no reason
to stop the release. It's certainly a good idea to do *another* release
in the near future to address it, but not to keep the fixes between
5.5.26 and 5.5.27 out of users' hands.
I think using your definition, it is then a regression.
For me this is a critical error. Tomcat 5.5.26 and 5.5.27 don't work
when run under the security manager.
It's really not a trivial corner case. Did you look at my stack trace
from Saturday? Trying to open a socket in one part of my code triggered
the bug. The class loader is looking for a logging.properties in
context/WEB-INF/classes and it's bombing.
I'm really not trying to be overly picky here, but if the whole security
manager functionality is broken, that's a pretty big thing. The fact
that it was broken in the last release, and will be broken in the new
release is even worse.
From now until the NEXT release is created, people will be posting it
as a bug, which will then get marked RESOLVED, INVALID. They will then
re-open and wonder why it was closed. It will then be explained that the
fix is in CVS and that's why it was closed. The end user will then want
to know when the release with the fix will be present.
Whatever. I've made my opinion known. If the release gets done with the
bug still in it, then I'm a big enough boy to apply the patch and
re-compile it so things work.
--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL: http://www.mhsoftware.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
