You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Dan Milstein <da...@shore.net> on 2001/02/02 18:24:27 UTC
3.2.2 Release?
There was some discussion about producing a 3.2.2 release at some point
soonish. Where is that now? People have contributed some excellent fixes
in the connector area, and I would love to see those available to the
general public.
I'm not in a position to function as the Release Manager, but I can help
collect info about what fixes have been made in the mod_jk/connector area.
-Dan
--
Dan Milstein // danmil@shore.net
Re: 3.2.2 Release?
Posted by Dan Milstein <da...@shore.net>.
tomcat_32 is the right place -- it is a branch which is up to date for all
fixes which have been made against 3.2 (including 3.2.1). The other various
3.2 looking things in cvs (e.g. 321_final) are tags but not branches.
I'm working on urlencoding stuff right now, so I await your patch with bated
breath ;-).
-Dan
David Weinrich wrote:
>
> On a somewhat unrelated note...
> I noticed a bugrat report this morning on an urlencoding that I had
> submitted a patch for a little while back ( which was flawed/incomplete ).
> In the process of redoing the patch and grabbing the source from cvs I came
> up against this issue: what the heck tag is appropriate to use to submit
> bugfixes against for the 3.2.x version of Tomcat? I am assuming that
> tomcat_32 is the appropriate place but...
--
Dan Milstein // danmil@shore.net
Re: 3.2.2 Release?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
David Weinrich wrote:
> On a somewhat unrelated note...
> I noticed a bugrat report this morning on an urlencoding that I had
> submitted a patch for a little while back ( which was flawed/incomplete ).
> In the process of redoing the patch and grabbing the source from cvs I came
> up against this issue: what the heck tag is appropriate to use to submit
> bugfixes against for the 3.2.x version of Tomcat? I am assuming that
> tomcat_32 is the appropriate place but...
>
Yes, that is the correct place -- "tomcat_32" is a branch that contains the
current state of the 3.2 codebase (i.e. all the patches for 3.2.1, plus patches
that have been committed since then).
Craig
Re: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was
'Re: 3.2.2 Release?'
Posted by cm...@yahoo.com.
> Just checking back on the status of this patch, I received some email from
> someone who isn't actively on the list but has the same problem as
> originally reported in Bugrat report 723. Anyone have any feedback on the
> patch or the control characters in URL question I had?
I will work on it for 3.3 , there are few more encoding problems and I
need a bit of time. I don't think we can do it for M1, but it is on the
list and it has high priority.
( I don't know if they are checked into 3.2.x )
Costin
>
> David Weinrich
>
> ----- Original Message -----
> From: "David Weinrich" <dw...@home.com>
> To: "Tomcat Dev List" <to...@jakarta.apache.org>
> Sent: Friday, February 02, 2001 23:18
> Subject: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re:
> 3.2.2 Release?'
>
> Thanks to everyone, that cleared things up quite a bit. Here is the patch
> for bugrat report 723 ( tomcat 3.2.x not unescaping escaped urls ). The
> patch is extremely short, and implemented a tiny bit different from the one
> I sent in for 3.2.x a while ago, the unencoding is done before the path is
> checked for other issues/security concerns to prevent unencoded stuff from
> causing these after the fact.
> Note: I haven't yet mastered the art of Watchdog/internal tomcat tests so
> this will need to be tested a bit more thoroughly. So far the following urls
> work correctly:
>
> http://localhost:8080/index%20%23%24.jsp
> http://localhost:8080/index%20%23%24.html
>
> corresponding to the following filenames in the ROOT webapp dir:
>
> 'index #$.jsp' and
> 'index #$.html'
>
> If an error occurs in unencoding, null is returned which ends up sending a
> Not Found(404) message instead of a stack trace. This seemed to be the most
> sane way to handle the issue of improperly encoded urls. This is usually the
> result of having a value after a % that isn't two hex digits or having an
> unencoded % in the url like:
>
> http://localhost:8080/index%%20%23%24.jsp or
> http://localhost:8080/index%zz%23%24.jsp
>
> One last remaining concern I have: the current implementation of RequestUtil
> allows control characters to pass through without raising an exception, I am
> assuming this could possibly raise problems, and is fairly undesired. If I
> interpret http://www.ietf.org/rfc/rfc2396.txt correctly, control characters
> should not be included in URLs. If it is agreeable, I will make a patch to
> RequestUtil.URLDecode tomorrow to block characters in the ranges of 00-1f
> and 7f-9f to prevent this from being a potential problem. Thanks again!
>
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
--
Costin
Re: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re: 3.2.2 Release?'
Posted by David Weinrich <dw...@home.com>.
Just checking back on the status of this patch, I received some email from
someone who isn't actively on the list but has the same problem as
originally reported in Bugrat report 723. Anyone have any feedback on the
patch or the control characters in URL question I had?
David Weinrich
----- Original Message -----
From: "David Weinrich" <dw...@home.com>
To: "Tomcat Dev List" <to...@jakarta.apache.org>
Sent: Friday, February 02, 2001 23:18
Subject: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re:
3.2.2 Release?'
Thanks to everyone, that cleared things up quite a bit. Here is the patch
for bugrat report 723 ( tomcat 3.2.x not unescaping escaped urls ). The
patch is extremely short, and implemented a tiny bit different from the one
I sent in for 3.2.x a while ago, the unencoding is done before the path is
checked for other issues/security concerns to prevent unencoded stuff from
causing these after the fact.
Note: I haven't yet mastered the art of Watchdog/internal tomcat tests so
this will need to be tested a bit more thoroughly. So far the following urls
work correctly:
http://localhost:8080/index%20%23%24.jsp
http://localhost:8080/index%20%23%24.html
corresponding to the following filenames in the ROOT webapp dir:
'index #$.jsp' and
'index #$.html'
If an error occurs in unencoding, null is returned which ends up sending a
Not Found(404) message instead of a stack trace. This seemed to be the most
sane way to handle the issue of improperly encoded urls. This is usually the
result of having a value after a % that isn't two hex digits or having an
unencoded % in the url like:
http://localhost:8080/index%%20%23%24.jsp or
http://localhost:8080/index%zz%23%24.jsp
One last remaining concern I have: the current implementation of RequestUtil
allows control characters to pass through without raising an exception, I am
assuming this could possibly raise problems, and is fairly undesired. If I
interpret http://www.ietf.org/rfc/rfc2396.txt correctly, control characters
should not be included in URLs. If it is agreeable, I will make a patch to
RequestUtil.URLDecode tomorrow to block characters in the ranges of 00-1f
and 7f-9f to prevent this from being a potential problem. Thanks again!
David
[PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re: 3.2.2 Release?'
Posted by David Weinrich <dw...@home.com>.
Thanks to everyone, that cleared things up quite a bit. Here is the patch
for bugrat report 723 ( tomcat 3.2.x not unescaping escaped urls ). The
patch is extremely short, and implemented a tiny bit different from the one
I sent in for 3.2.x a while ago, the unencoding is done before the path is
checked for other issues/security concerns to prevent unencoded stuff from
causing these after the fact.
Note: I haven't yet mastered the art of Watchdog/internal tomcat tests so
this will need to be tested a bit more thoroughly. So far the following urls
work correctly:
http://localhost:8080/index%20%23%24.jsp
http://localhost:8080/index%20%23%24.html
corresponding to the following filenames in the ROOT webapp dir:
'index #$.jsp' and
'index #$.html'
If an error occurs in unencoding, null is returned which ends up sending a
Not Found(404) message instead of a stack trace. This seemed to be the most
sane way to handle the issue of improperly encoded urls. This is usually the
result of having a value after a % that isn't two hex digits or having an
unencoded % in the url like:
http://localhost:8080/index%%20%23%24.jsp or
http://localhost:8080/index%zz%23%24.jsp
One last remaining concern I have: the current implementation of RequestUtil
allows control characters to pass through without raising an exception, I am
assuming this could possibly raise problems, and is fairly undesired. If I
interpret http://www.ietf.org/rfc/rfc2396.txt correctly, control characters
should not be included in URLs. If it is agreeable, I will make a patch to
RequestUtil.URLDecode tomorrow to block characters in the ranges of 00-1f
and 7f-9f to prevent this from being a potential problem. Thanks again!
David
----- Original Message -----
From: "Marc Saegesser" <ma...@apropos.com>
To: <to...@jakarta.apache.org>
Sent: Friday, February 02, 2001 12:44
Subject: RE: 3.2.2 Release?
> You are correct, tomcat_32 is the appropriate tag. tomcat_32 is a branch
> tag so if you use cvs to check out jakarta-tomcat like
>
> cvs co -r tomcat_32 jakarta-tomcat
>
> then you'll get the latest version of all files on this branch. This is
> referred to as the "tip" of the branch.
>
> The labels like tomcat_32_final and tomcat_321_final label a particular
> version of a file so the command
>
> cvs co -r tomcat_321_final jakarta-tomcat
>
> will retrieve the versions of all the files that make up the Tomcat 3.2.1
> release.
>
> The code that is (most likely) destined to become Tomcat 3.3 is the main
> branch of the repository, often referred to as the "HEAD". To get this
code
> from cvs use a command like
>
> cvs co jakarta-tomcat
>
> When Tomcat 3.3 is released a new branch will be created called tomcat_33
> and this will form the basis for all bug fixes and patches for the 3.3
> release. The HEAD will then become the code base for any new feature
> development of the 3.x repository.
>
> > -----Original Message-----
> > From: David Weinrich [mailto:dweinr1@home.com]
> > Sent: Friday, February 02, 2001 2:31 PM
> > To: Tomcat Dev List
> > Subject: Re: 3.2.2 Release?
> >
> >
> > On a somewhat unrelated note...
> > I noticed a bugrat report this morning on an urlencoding that I had
> > submitted a patch for a little while back ( which was
flawed/incomplete ).
> > In the process of redoing the patch and grabbing the source from
> > cvs I came
> > up against this issue: what the heck tag is appropriate to use to submit
> > bugfixes against for the 3.2.x version of Tomcat? I am assuming that
> > tomcat_32 is the appropriate place but...
> >
> >
> >
> > ----- Original Message -----
> > From: "Marc Saegesser" <ma...@apropos.com>
> > To: <to...@jakarta.apache.org>
> > Sent: Friday, February 02, 2001 11:04
> > Subject: RE: 3.2.2 Release?
> >
> >
> > > One thing I don't see listed here, and is the biggest reason I
> > don't think
> > I
> > > have the time to manage the release, is determining what bugs
> > still exist
> > in
> > > the tomcat_32 branch and which of those, if any, should be fixed
before
> > > releasing 3.2.2. This was an issue that Jon raised regarding the 3.3
> > > release plan. What is the feeling of the Tomcat development
community?
> > Can
> > > we get away with just releasing the tip of tomcat_32 as-is or
> > would such a
> > > release *require* a complete review of open bugs and should the
> > release be
> > > held until these bugs are all addressed.
> > >
> > > I've been trying to make just such a review but it has been very time
> > > consuming. Maybe, since this is just a minor point release to
> > an existing
> > > product, we can go with what we have.
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
RE: 3.2.2 Release?
Posted by Marc Saegesser <ma...@apropos.com>.
You are correct, tomcat_32 is the appropriate tag. tomcat_32 is a branch
tag so if you use cvs to check out jakarta-tomcat like
cvs co -r tomcat_32 jakarta-tomcat
then you'll get the latest version of all files on this branch. This is
referred to as the "tip" of the branch.
The labels like tomcat_32_final and tomcat_321_final label a particular
version of a file so the command
cvs co -r tomcat_321_final jakarta-tomcat
will retrieve the versions of all the files that make up the Tomcat 3.2.1
release.
The code that is (most likely) destined to become Tomcat 3.3 is the main
branch of the repository, often referred to as the "HEAD". To get this code
from cvs use a command like
cvs co jakarta-tomcat
When Tomcat 3.3 is released a new branch will be created called tomcat_33
and this will form the basis for all bug fixes and patches for the 3.3
release. The HEAD will then become the code base for any new feature
development of the 3.x repository.
> -----Original Message-----
> From: David Weinrich [mailto:dweinr1@home.com]
> Sent: Friday, February 02, 2001 2:31 PM
> To: Tomcat Dev List
> Subject: Re: 3.2.2 Release?
>
>
> On a somewhat unrelated note...
> I noticed a bugrat report this morning on an urlencoding that I had
> submitted a patch for a little while back ( which was flawed/incomplete ).
> In the process of redoing the patch and grabbing the source from
> cvs I came
> up against this issue: what the heck tag is appropriate to use to submit
> bugfixes against for the 3.2.x version of Tomcat? I am assuming that
> tomcat_32 is the appropriate place but...
>
>
>
> ----- Original Message -----
> From: "Marc Saegesser" <ma...@apropos.com>
> To: <to...@jakarta.apache.org>
> Sent: Friday, February 02, 2001 11:04
> Subject: RE: 3.2.2 Release?
>
>
> > One thing I don't see listed here, and is the biggest reason I
> don't think
> I
> > have the time to manage the release, is determining what bugs
> still exist
> in
> > the tomcat_32 branch and which of those, if any, should be fixed before
> > releasing 3.2.2. This was an issue that Jon raised regarding the 3.3
> > release plan. What is the feeling of the Tomcat development community?
> Can
> > we get away with just releasing the tip of tomcat_32 as-is or
> would such a
> > release *require* a complete review of open bugs and should the
> release be
> > held until these bugs are all addressed.
> >
> > I've been trying to make just such a review but it has been very time
> > consuming. Maybe, since this is just a minor point release to
> an existing
> > product, we can go with what we have.
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: 3.2.2 Release?
Posted by David Weinrich <dw...@home.com>.
On a somewhat unrelated note...
I noticed a bugrat report this morning on an urlencoding that I had
submitted a patch for a little while back ( which was flawed/incomplete ).
In the process of redoing the patch and grabbing the source from cvs I came
up against this issue: what the heck tag is appropriate to use to submit
bugfixes against for the 3.2.x version of Tomcat? I am assuming that
tomcat_32 is the appropriate place but...
----- Original Message -----
From: "Marc Saegesser" <ma...@apropos.com>
To: <to...@jakarta.apache.org>
Sent: Friday, February 02, 2001 11:04
Subject: RE: 3.2.2 Release?
> One thing I don't see listed here, and is the biggest reason I don't think
I
> have the time to manage the release, is determining what bugs still exist
in
> the tomcat_32 branch and which of those, if any, should be fixed before
> releasing 3.2.2. This was an issue that Jon raised regarding the 3.3
> release plan. What is the feeling of the Tomcat development community?
Can
> we get away with just releasing the tip of tomcat_32 as-is or would such a
> release *require* a complete review of open bugs and should the release be
> held until these bugs are all addressed.
>
> I've been trying to make just such a review but it has been very time
> consuming. Maybe, since this is just a minor point release to an existing
> product, we can go with what we have.
>
RE: 3.2.2 Release?
Posted by Marc Saegesser <ma...@apropos.com>.
One thing I don't see listed here, and is the biggest reason I don't think I
have the time to manage the release, is determining what bugs still exist in
the tomcat_32 branch and which of those, if any, should be fixed before
releasing 3.2.2. This was an issue that Jon raised regarding the 3.3
release plan. What is the feeling of the Tomcat development community? Can
we get away with just releasing the tip of tomcat_32 as-is or would such a
release *require* a complete review of open bugs and should the release be
held until these bugs are all addressed.
I've been trying to make just such a review but it has been very time
consuming. Maybe, since this is just a minor point release to an existing
product, we can go with what we have.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Friday, February 02, 2001 12:44 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: 3.2.2 Release?
>
>
> Dan Milstein wrote:
>
> > Can someone who has functioned as a release manager for a dot
> release give
> > me a quick overview of what's involved? I may be able to find
> the time, but
> > I'm not totally clear on the scope of what needs to happen.
> >
>
> What's involved is essentially:
> * Propose the release plan ("I propose to mark the 'tomcat_32"
> branch on date x/y/zzzz and release it as version 3.2.2")
> for a vote on TOMCAT-DEV.
> * Normally, such a plan also includes a temporary freeze on
> commits to that branch, unless you do them (to pick up last
> minute patches) or delegate the commits for those issues.
> * If the number of changes is large enough, you might want
> to do a "release candidate" ahead of the actual release for
> people to bang against. 3.2.2 has had enough patches that
> this might be a good idea. (Nightly builds would also serve
> this role -- it would be *great* if Costin had time to set this
> up as part of his nightly run).
> * On the day of reckoning, do a CVS tag of the correct
> code (probably with a tag like "tomcat_322_final").
> * Build binary and source distributions in all the usual formats,
> and publish them to the Jakarta web site.
> * Build native code binaries for as many platforms as you can
> gather, and publish them too.
> * Announce the release on the Jakarta web site, plus to the
> following Jakarta mailing lists: ANNOUNCEMENTS, GENERAL,
> TOMCAT-DEV, and TOMCAT-USER.
>
> I can assist with questions on the mechanics, but don't have time
> to do the
> entire job.
>
>
> >
> > I don't think Milestone releases would make sense -- from what
> it says on
> > http://jakarta.apache.org/site/binindex.html, those sound like
> they should
> > really be steps towards a major release of new functionality,
> not snapshots
> > of bug fixes in a released product. Nightly builds I would be
> fine with,
> > however.
> >
> > -Dan
> >
>
> Craig
>
>
> >
> > cmanolache@yahoo.com wrote:
> > >
> > > > I'm in the same boat right now. I'd love to a 3.2.2
> released but I'm way
> > > > too busy right now to manage a release.
> > >
> > > What about a "milestone" ? It doesn't have all the requirements of a
> > > release. I can add a nightly build of 3.2.x to my scripts too
> ? ( it'll
> > > not be a "blessed" release, but people who need the patches
> can use it ).
> > >
> > > Costin
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> >
> > --
> >
> > Dan Milstein // danmil@shore.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: 3.2.2 Release?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Dan Milstein wrote:
> Can someone who has functioned as a release manager for a dot release give
> me a quick overview of what's involved? I may be able to find the time, but
> I'm not totally clear on the scope of what needs to happen.
>
What's involved is essentially:
* Propose the release plan ("I propose to mark the 'tomcat_32"
branch on date x/y/zzzz and release it as version 3.2.2")
for a vote on TOMCAT-DEV.
* Normally, such a plan also includes a temporary freeze on
commits to that branch, unless you do them (to pick up last
minute patches) or delegate the commits for those issues.
* If the number of changes is large enough, you might want
to do a "release candidate" ahead of the actual release for
people to bang against. 3.2.2 has had enough patches that
this might be a good idea. (Nightly builds would also serve
this role -- it would be *great* if Costin had time to set this
up as part of his nightly run).
* On the day of reckoning, do a CVS tag of the correct
code (probably with a tag like "tomcat_322_final").
* Build binary and source distributions in all the usual formats,
and publish them to the Jakarta web site.
* Build native code binaries for as many platforms as you can
gather, and publish them too.
* Announce the release on the Jakarta web site, plus to the
following Jakarta mailing lists: ANNOUNCEMENTS, GENERAL,
TOMCAT-DEV, and TOMCAT-USER.
I can assist with questions on the mechanics, but don't have time to do the
entire job.
>
> I don't think Milestone releases would make sense -- from what it says on
> http://jakarta.apache.org/site/binindex.html, those sound like they should
> really be steps towards a major release of new functionality, not snapshots
> of bug fixes in a released product. Nightly builds I would be fine with,
> however.
>
> -Dan
>
Craig
>
> cmanolache@yahoo.com wrote:
> >
> > > I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
> > > too busy right now to manage a release.
> >
> > What about a "milestone" ? It doesn't have all the requirements of a
> > release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll
> > not be a "blessed" release, but people who need the patches can use it ).
> >
> > Costin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
> --
>
> Dan Milstein // danmil@shore.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: 3.2.2 Release?
Posted by Dan Milstein <da...@shore.net>.
Can someone who has functioned as a release manager for a dot release give
me a quick overview of what's involved? I may be able to find the time, but
I'm not totally clear on the scope of what needs to happen.
I don't think Milestone releases would make sense -- from what it says on
http://jakarta.apache.org/site/binindex.html, those sound like they should
really be steps towards a major release of new functionality, not snapshots
of bug fixes in a released product. Nightly builds I would be fine with,
however.
-Dan
cmanolache@yahoo.com wrote:
>
> > I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
> > too busy right now to manage a release.
>
> What about a "milestone" ? It doesn't have all the requirements of a
> release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll
> not be a "blessed" release, but people who need the patches can use it ).
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
Dan Milstein // danmil@shore.net
Re: 3.2.2 Release?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com wrote:
> > I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
> > too busy right now to manage a release.
>
> What about a "milestone" ? It doesn't have all the requirements of a
> release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll
> not be a "blessed" release, but people who need the patches can use it ).
>
It would be great if you had time to add a nightly build of the "tomcat_32"
branch as well.
> Costin
>
Craig
RE: 3.2.2 Release?
Posted by cm...@yahoo.com.
> I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
> too busy right now to manage a release.
What about a "milestone" ? It doesn't have all the requirements of a
release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll
not be a "blessed" release, but people who need the patches can use it ).
Costin
RE: 3.2.2 Release?
Posted by Marc Saegesser <ma...@apropos.com>.
I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
too busy right now to manage a release.
> -----Original Message-----
> From: danmil [mailto:danmil]On Behalf Of Dan Milstein
> Sent: Friday, February 02, 2001 11:24 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: 3.2.2 Release?
>
>
> There was some discussion about producing a 3.2.2 release at some point
> soonish. Where is that now? People have contributed some excellent fixes
> in the connector area, and I would love to see those available to the
> general public.
>
> I'm not in a position to function as the Release Manager, but I can help
> collect info about what fixes have been made in the mod_jk/connector area.
>
> -Dan
> --
>
> Dan Milstein // danmil@shore.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org