FYI: Tomcat 4.0 Release Planning Futures

["Craig R. McClanahan" <cr...@apache.org>]

Many TOMCAT-DEV readers might be unaware that the Apache Software
Foundation (the group that sponsors the Jakarta project, along with many
others) is an Executive Member of the Java Community Process program,
which is the group which accepts or rejects the Java Specification
Requests (JSRs) that create new Java API standards.  The JSR that most
directly affects the Tomcat community is JSR-053, under which the new
specifications for Servlet 2.3 and JSP 1.2 are being developed.  Jason
Hunter is our voting representative.

This membership position gives ASF (and the open source developers that
ASF represents) a powerful voice in shaping the future of the Java
platform.  In addition, however, it imposes responsibilities to follow the
rules of the Java Community Process -- the same rules that software
vendors creating products based on these specifications must follow.

One particular restriction that affects Tomcat 4.0 is the following -- no
one is allowed to release a "final" release of a product that implements a
Java specification that is not itself final.  That is the current state of
the Servlet 2.3 and JSP 1.2 specifications -- they are in "Proposed Final
Draft" state at the moment.  Therefore, we can not choose to create a
"final" release of Tomcat 4.0 until those specifications are finalized
(which is likely to be several months yet).

The reasoning behind this standard is obvious -- the specifications being
implemented can still change.  In fact, several changes approved by the
JSR-053 expert group have been implemented in the last week (they will
appear in the next draft of the servlet specification).  It would be very
confusing, for example, to have "final" servlet containers from different
vendors that implemented different variations of the servlet 2.3 spec.

So where does that leave us in the mean time?  I propose that we continue
to innovate new features in succeeding beta releases of Tomcat 4.0
(treating them essentially the way that "milestone" releases get treated
in many development projects).  The quality of the code, and overall
performance, will continue to improve, and beta releases would be cut only
at points where the code is stable, and passes all current compliance
tests.

If need be, we could create a "production quality" release, as long as
users understand that the fact that the underlying specifications are
still subject to change.  Such a release could probably be named "Tomcat
4.0 Proposed Final", to correspond with the nomenclature on the
specifications it is based on.  However, in practical reality such a
release would be essentially the same as another beta (in terms of overall
quality, testing, and so on).

Comments?  Questions?

Craig McClanahan

Re: FYI: Tomcat 4.0 Release Planning Futures

[Glenn Nielsen <gl...@voyager.apg.more.net>]

+1 

"Craig R. McClanahan" wrote:
> 
> Many TOMCAT-DEV readers might be unaware that the Apache Software
> Foundation (the group that sponsors the Jakarta project, along with many
> others) is an Executive Member of the Java Community Process program,
> which is the group which accepts or rejects the Java Specification
> Requests (JSRs) that create new Java API standards.  The JSR that most
> directly affects the Tomcat community is JSR-053, under which the new
> specifications for Servlet 2.3 and JSP 1.2 are being developed.  Jason
> Hunter is our voting representative.
> 
> This membership position gives ASF (and the open source developers that
> ASF represents) a powerful voice in shaping the future of the Java
> platform.  In addition, however, it imposes responsibilities to follow the
> rules of the Java Community Process -- the same rules that software
> vendors creating products based on these specifications must follow.
> 
> One particular restriction that affects Tomcat 4.0 is the following -- no
> one is allowed to release a "final" release of a product that implements a
> Java specification that is not itself final.  That is the current state of
> the Servlet 2.3 and JSP 1.2 specifications -- they are in "Proposed Final
> Draft" state at the moment.  Therefore, we can not choose to create a
> "final" release of Tomcat 4.0 until those specifications are finalized
> (which is likely to be several months yet).
> 
> The reasoning behind this standard is obvious -- the specifications being
> implemented can still change.  In fact, several changes approved by the
> JSR-053 expert group have been implemented in the last week (they will
> appear in the next draft of the servlet specification).  It would be very
> confusing, for example, to have "final" servlet containers from different
> vendors that implemented different variations of the servlet 2.3 spec.
> 
> So where does that leave us in the mean time?  I propose that we continue
> to innovate new features in succeeding beta releases of Tomcat 4.0
> (treating them essentially the way that "milestone" releases get treated
> in many development projects).  The quality of the code, and overall
> performance, will continue to improve, and beta releases would be cut only
> at points where the code is stable, and passes all current compliance
> tests.
> 
> If need be, we could create a "production quality" release, as long as
> users understand that the fact that the underlying specifications are
> still subject to change.  Such a release could probably be named "Tomcat
> 4.0 Proposed Final", to correspond with the nomenclature on the
> specifications it is based on.  However, in practical reality such a
> release would be essentially the same as another beta (in terms of overall
> quality, testing, and so on).
> 
> Comments?  Questions?
> 
> Craig McClanahan

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: FYI: Tomcat 4.0 Release Planning Futures

[James Duncan Davidson <du...@x180.net>]

> This membership position gives ASF (and the open source developers that
> ASF represents) a powerful voice in shaping the future of the Java
> platform.  In addition, however, it imposes responsibilities to follow 
> the
> rules of the Java Community Process -- the same rules that software
> vendors creating products based on these specifications must follow.

Actually, it's not the fact that the ASF is part of the JCP that makes 
us follow that. The restrictions are placed on anybody who uses the spec 
by the spec license on the back front page. This means that anybody 
implementing servlets is required, by "accepting" that license to follow 
it. At least the way the license is designed.

Do not assume that I agree with the way things are -- I'm just reporting 
my understanding of the way things are set up.

.duncan

Re: FYI: Tomcat 4.0 Release Planning Futures

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 20 Mar 2001, Kief Morris wrote:

> Craig R. McClanahan typed the following on 08:52 PM 3/19/2001 -0800
> >So where does that leave us in the mean time?  I propose that we continue
> >to innovate new features in succeeding beta releases of Tomcat 4.0
> >(treating them essentially the way that "milestone" releases get treated
> >in many development projects).  The quality of the code, and overall
> >performance, will continue to improve, and beta releases would be cut only
> >at points where the code is stable, and passes all current compliance
> >tests.
> 
> +1 on this. I'm in a position now where I can start devoting some time
> to this (I've been on the road for the past month), especially the
> persistent & distributed sessions.
> 

Boy do I know about "on the road" :-).  I was in New York for a week,
and arrived in Boston half an hour before it snowed twelve inches in
twelve hours a couple weeks ago.

> Kief
> 
> 

Craig

Re: FYI: Tomcat 4.0 Release Planning Futures

[Kief Morris <ki...@bitbull.com>]

Craig R. McClanahan typed the following on 08:52 PM 3/19/2001 -0800
>So where does that leave us in the mean time?  I propose that we continue
>to innovate new features in succeeding beta releases of Tomcat 4.0
>(treating them essentially the way that "milestone" releases get treated
>in many development projects).  The quality of the code, and overall
>performance, will continue to improve, and beta releases would be cut only
>at points where the code is stable, and passes all current compliance
>tests.

+1 on this. I'm in a position now where I can start devoting some time
to this (I've been on the road for the past month), especially the
persistent & distributed sessions.

Kief