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:[EMAIL PROTECTED]]
> Sent: Friday, February 02, 2001 12:44 PM
> To: [EMAIL PROTECTED]
> 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
>
>
> >
> > [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> > --
> >
> > Dan Milstein // [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
