tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: How close 'till release?
Date Fri, 23 Aug 2002 16:46:04 GMT


On Fri, 23 Aug 2002, WATKIN-JONES,ADAM (HP-UnitedKingdom,ex1) wrote:

> Date: Fri, 23 Aug 2002 17:38:17 +0100
> From: "WATKIN-JONES,ADAM (HP-UnitedKingdom,ex1)"
>     <adam_watkin-jones@hp.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> Subject: RE: How close 'till release?
>
> Isn't there a danger that under this scheme stable releases will never occur
> because new code is continually being introduced?  i.e., a release branch is
> never created and the code head just carries on.

Yes.  The eternal battle between stability and "one more cool feature"
happens with this scheme just like with every other release management
scheme.

>
> Doesn't someone have to say "No new code.  Bugfixes only until we get a
> stable release."?  In which case, has this happened?
>

Sort of, it has, but in this scheme it is not as clear cut as
"freezing".  In fact, there will very likely be continued development on
the 4.1.x codebase, and therefore more than one 4.1.x release that is
voted to be of release quality.  And this will likely happen in parallel
with development on 5.0.x (which supports the new Servlet 2.4 and JSP 2.0
features) for a time.

In addition, any release management scheme shouldn't need to halt
innovation along the 4.1.x train -- it's pretty straightforward to manage
which dot release a particular new feature is added in, and work on it in
the mean time, without disrupting stability.

The other nice thing about Tomcat (being open source) is that you can get
involved yourself if you don't like the way things are being done :-).

  http://jakarta.apache.org/site/getinvolved.html

> Thanks,
> Adam
>

Craig


>
> -----Original Message-----
> From: Craig R. McClanahan
> Sent: 23 August 2002 17:27
>
>
>
> On Fri, 23 Aug 2002, Wills, Mike N. (TC) wrote:
>
> > Date: Fri, 23 Aug 2002 09:59:35 -0500
> > From: "Wills, Mike N. (TC)" <MNWills@taylorcorp.com>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> > Subject: How close 'till release?
> >
> > How close is Tomcat 4.1 to release?
>
> As others have mentioned, Tomcat 4.1 is following the release policy that
> is used for Apache's httpd web server and many other projects.  Basically,
> it goes like this:
>
> * Periodically, cut a milestone by incrementing the third part of the
>   version number (we're up to 4.1.9 so far).
>
> * Make the milestone available for testing (they get announced on
>   TOMCAT-DEV and TOMCAT-USER only) but with no claims for quality.
>
> * If a showstopper problem is found, the milestone is abandoned
>   (this has happened several times in 4.1 so far).
>
> * After a while, a vote takes place on TOMCAT-DEV about labelling
>   the quality of that milestone (typically, the options are
>   Alpha, Beta, or Release).  This label is attached to the version
>   number when the milestone is announced more widely.
>
> It took Apache 2.0 roughly 35 milestones (and over two years) to get to
> the point where the developers were satisfied with the quality.  I'm sure
> it won't take that long for Tomcat 4.1 because we weren't starting from
> scratch -- it's mostly incremental improvements on 4.0 code.  But it's
> going to take as long as it takes.
>
> > I won't install 4.1 on our production
> > system until it has gone to release.
> >
>
> I know lots of IT folks who follow this policy, but I have to smile when
> people say it.  Given the above release policy, think about what you'd be
> doing if 4.1.9 had been voted as "release" quality instead of "beta"
> quality.  You'd have installed it, right?  And it would have been
> *exactly* the same code ...
>
> The best way for Tomcat *users* to help get Tomcat 4.1 to general release
> state is trying it on your real apps, and reporting bugs so we can swat
> them.
>
> > Mike Wills
> > IT Corporate Support
> >
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message