You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Peter M. Goldstein" <pe...@yahoo.com> on 2002/11/22 03:52:30 UTC
Release Plan v2.1 (update)
All,
> Documentation and testing comprise the bulk of the remaining work. We
> still need to carry out the following documentation tasks:
>
> i) Document the configuration files in toto. Format the documentation
> consistently, as well as vet it for correctness.
In process. Assigned to me. I will be checking in some stuff tonight.
> ii) Document the top 5 items on the TODO list
In process. Assigned to me.
> iii) Add FetchPOP documentation
I'd really like someone to contribute on this one. Volunteers?
> iv) Produce a consistent documentation package for the 2.1 version
that
> details the product services, as well as the basic steps of
installation
> and configuration.
>
> Build tasks:
>
> i) Build a milestone build for testing.
Done. And posted.
> ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> permitting radical change for the 3.0 revision.
I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
it if I have to. Basically I'd suggest that we form a release/2.1
directory off the base directory that contains all the necessary files
to build a 2.1 release. This will allow bugfixing on that release.
> i) Run general tests on a variety of platforms. We've already done a
> great deal of testing on both Windows and Linux platforms, but it
would
> be good to get a great deal more testing done before the official
> release. We should look to our user base for potential testers.
The user base has started doing some testing. A request for feedback
has been posted on the web site. Not sure if anyone else wants to sign
up for more testing.
> ii) Test TLS support for POP3 and update the status from experimental
to
> stable.
Any volunteers?
> Marketing tasks:
>
> i) Produce a press release for distribution through channels
announcing
> both the release of 2.1 and inviting developers to participate in
> version 3.0.
In process. Assigned to me.
> ii) Distribute this release through channels (i.e. Slashdot)
In process. Assigned to me.
> iii) Ensure that we are listed on common sites that provide lists of
> available mail/news servers.
Any volunteers?
> I'm working on items i, ii, and iv on the documentation task list, as
> well as items i and iii on the marketing task list. Anyone who wants
to
> step up for any of the other items, please do. I'd like to ask Danny
> specifically to address the milestone build issue, since he has write
> access to the web site. If he can get me such write access, I'd be
> happy to build and post the milestone build.
I haven't really gotten any response from any of the
committers/contributors to this request for contributions. If we're
going to get this out the door, it's going to require some effort from a
number of interested parties. I know this stuff doesn't interest most
of us (it certainly doesn't interest me) but it's part and parcel of
putting out an enterprise class product.
> Here's my desired schedule:
>
> November 4th, 2002 - Creation and posting of milestone build
Completed November 13th, 2002.
> November 4th-17th, 2002 - Testing period. Aggressive testing of James
> under a variety of conditions.
Testing can be considered to be started November 13th, which would lead
to a close of this period on November 26th. There has been some testing
to date,
> November 8th, 2002 - Documentation freeze, which requires completion
of
> all documentation tasks.
We're way off on this one. :)
I'm still not done with the segments of documentation I signed up for,
and no one else has picked up the remainder. I'd like to set a nominal
freeze date of November 26th, but unless we get some contributions,
that's not going to happen.
> November 15th, 2002 - Completion of press release, list of sites to
> which the release needs to be distributed. Mail server info sites
> should be updated with links at this point.
I'd say this should be November 30th. But it depends on all the earlier
steps. And hence depends on people contributing.
> November 18th, 2002 - Release. Update of web site to reflect newly
> released version. Distribution of press release to sites should be
> completed immediately after release.
I'd say December 2nd for this. But again, this depends on everyone
stepping up and contributing.
Thoughts? Replies? Anyone? :)
--Peter
P.S.: I understand that Thanksgiving falls in the middle of this, but
there just isn't that much left to do. One last push should get us over
the edge.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
> > iii) Add FetchPOP documentation
> I'd really like someone to contribute on this one. Volunteers?
If Danny can't do it, I'll take a look. I'm not familiar with it, though,
so I'll have to go from the source code.
> ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> permitting radical change for the 3.0 revision.
Please review Charles Bennett's message from 13 October:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg03999.html. I'm
not a CVS guru, either. Charles understood the goal that we have, and
posted the way by which he said that we do it. Basically, we just have to
tag the release as we would normally do. After that, branching is deferred
until actually needed.
I'm going to merge my live configuration with the new distribution, and then
post it to my production server.
> iii) Ensure that we are listed on common sites that provide lists of
> available mail/news servers.
I think that we can all pitch in here, and we ought to ask our users if they
might help to spread the word post-release. I also think that our press
release should mention future plans, and invite interested developers to
contribute. If you want some help with the press release, let me know.
> I'm still not done with the segments of documentation I signed up for
> and no one else has picked up the remainder.
Other than FetchPOP, what's on the list?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Serge Knystautas wrote:
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
Doh!... build_2_1_1_fcs for James 2.1.1 (final)
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Charles Benett <ch...@apache.org>.
(this might be a duplicate - apologies if it is)
I agree with Serge's suggestions. My only question would be whether
James needs point releases (ie James 2.1.1) or whether we major and
minor are sufficient.
Charles
(Who used to have an account on Daedalus but hasn't checked recently)
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>> Serge,
>>
>> Never discussed, and Danny is probably the only one who has been
>> active and
>> CVS knowledgable enough to do it. I agree with you. I'd say I'm
>> sorry, but
>> I didn't even have commit rights until recently, and I still don't
>> know more
>> than just the basic CVS commands.
>>
>> Perhaps you, Charles and Danny could put together a brief
>> CVS-for-Committers
>> file? :-)
>>
>> --- Noel
>
>
> I would leave CVS guides to others more knowledgeable (there are three
> decent guides on http://jakarta.apache.org/site/library.html).
>
> But looking over our CVS repository, I would say we could benefit from
> standardizing on a tag/branching process. I would put forward this:
>
> 1. Tagging on publishing builds
>
> Aside from nightly builds, when we put a build on the website (an
> alpha, beta, release candidate, final release), we tag that in CVS
> using the naming convention
>
> build_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> Possible levels include "alpha", "beta", "rc" (release candidate), and
> "fcs" (first customer ship, i.e., final release).
>
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
> etc...
>
> 2. Branching on these tags as needed
>
> If a release has been made public for some time, new development has
> proceeded on HEAD, and there is a need to apply patches to make a
> minor or dot release on an old version, we branch on that tag, using
> the following naming convention:
>
> branch_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> For example, we had James 2.1 a1 out for a long time, so normally you
> wouldn't branch on an alpha release, but if we wanted to patch that
> version to make small releases while we were working out this current
> build, we could create a branch_2_1_a_1.
>
>
> Comments?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Alan Gerhard <al...@GerCom.Com>.
eventually we will need/use point releases - at least that is the goal; not to
have point releases but to be a major player in the enterprise mail server
space; once there we will have indeed point releases, so, if it's not too much
to set up now and adhere to .. well, it might be better in the long run.
alan
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Tuesday, November 26, 2002 3:46 PM
To: James Developers List
Subject: Re: Release Plan v2.1 (update)
Charles Benett wrote:
> I agree with Serge's suggestions. My only question would be whether
> James needs point releases (ie James 2.1.1) or whether we major and
> minor are sufficient.
>
> Charles
Yeah, good point.
I didn't mean to imply point releases or branching on alphas were
something we wanted to do very often. Normally I think we'd only do
either of those when we were focused on a new major/minor release, and
some security or other bug became so glaring that we wanted to make a
very minor bug fix release.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Charles Benett wrote:
> I agree with Serge's suggestions. My only question would be whether
> James needs point releases (ie James 2.1.1) or whether we major and
> minor are sufficient.
>
> Charles
Yeah, good point.
I didn't mean to imply point releases or branching on alphas were
something we wanted to do very often. Normally I think we'd only do
either of those when we were focused on a new major/minor release, and
some security or other bug became so glaring that we wanted to make a
very minor bug fix release.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Charles Benett <ch...@apache.org>.
I agree with Serge's suggestions. My only question would be whether
James needs point releases (ie James 2.1.1) or whether we major and
minor are sufficient.
Charles
(Who used to have an account on Daedalus but hasn't checked recently)
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>> Serge,
>>
>> Never discussed, and Danny is probably the only one who has been
>> active and
>> CVS knowledgable enough to do it. I agree with you. I'd say I'm
>> sorry, but
>> I didn't even have commit rights until recently, and I still don't
>> know more
>> than just the basic CVS commands.
>>
>> Perhaps you, Charles and Danny could put together a brief
>> CVS-for-Committers
>> file? :-)
>>
>> --- Noel
>
>
> I would leave CVS guides to others more knowledgeable (there are three
> decent guides on http://jakarta.apache.org/site/library.html).
>
> But looking over our CVS repository, I would say we could benefit from
> standardizing on a tag/branching process. I would put forward this:
>
> 1. Tagging on publishing builds
>
> Aside from nightly builds, when we put a build on the website (an
> alpha, beta, release candidate, final release), we tag that in CVS
> using the naming convention
>
> build_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> Possible levels include "alpha", "beta", "rc" (release candidate), and
> "fcs" (first customer ship, i.e., final release).
>
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
> etc...
>
> 2. Branching on these tags as needed
>
> If a release has been made public for some time, new development has
> proceeded on HEAD, and there is a need to apply patches to make a
> minor or dot release on an old version, we branch on that tag, using
> the following naming convention:
>
> branch_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> For example, we had James 2.1 a1 out for a long time, so normally you
> wouldn't branch on an alpha release, but if we wanted to patch that
> version to make small releases while we were working out this current
> build, we could create a branch_2_1_a_1.
>
>
> Comments?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Serge,
>
> Never discussed, and Danny is probably the only one who has been active and
> CVS knowledgable enough to do it. I agree with you. I'd say I'm sorry, but
> I didn't even have commit rights until recently, and I still don't know more
> than just the basic CVS commands.
>
> Perhaps you, Charles and Danny could put together a brief CVS-for-Committers
> file? :-)
>
> --- Noel
I would leave CVS guides to others more knowledgeable (there are three
decent guides on http://jakarta.apache.org/site/library.html).
But looking over our CVS repository, I would say we could benefit from
standardizing on a tag/branching process. I would put forward this:
1. Tagging on publishing builds
Aside from nightly builds, when we put a build on the website (an alpha,
beta, release candidate, final release), we tag that in CVS using the
naming convention
build_<major>_<minor>[_<point>]_<level>[_<counter>]
Possible levels include "alpha", "beta", "rc" (release candidate), and
"fcs" (first customer ship, i.e., final release).
For example...
- build_2_1_rc_1 for James 2.1 RC1
- then build_2_1_rc_2 for James 2.1 RC2
- then build_2_1_fcs for James 2.1 (final)
- then build_2_1_1_rc1 for James 2.1.1 RC1
- then build_2_1_1_fcs for James 2.1.2
etc...
2. Branching on these tags as needed
If a release has been made public for some time, new development has
proceeded on HEAD, and there is a need to apply patches to make a minor
or dot release on an old version, we branch on that tag, using the
following naming convention:
branch_<major>_<minor>[_<point>]_<level>[_<counter>]
For example, we had James 2.1 a1 out for a long time, so normally you
wouldn't branch on an alpha release, but if we wanted to patch that
version to make small releases while we were working out this current
build, we could create a branch_2_1_a_1.
Comments?
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Never discussed, and Danny is probably the only one who has been active and
CVS knowledgable enough to do it. I agree with you. I'd say I'm sorry, but
I didn't even have commit rights until recently, and I still don't know more
than just the basic CVS commands.
Perhaps you, Charles and Danny could put together a brief CVS-for-Committers
file? :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Danny Angus <da...@apache.org>.
no reason, I'll do that
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 23 November 2002 02:57
> To: James Developers List
> Subject: Re: Release Plan v2.1 (update)
>
>
> Danny Angus wrote:
> >>>ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> >>>permitting radical change for the 3.0 revision.
> >>
> >>I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
> >>it if I have to. Basically I'd suggest that we form a release/2.1
> >>directory off the base directory that contains all the necessary files
> >>to build a 2.1 release. This will allow bugfixing on that release.
> >
> >
> > I'll do this.
> > I'll tag 2.1 when the final code is checked out for the
> release, then if we need to mess around with it later we can
> branch CVS then (and only then)
>
> Was it discussed and/or is there a reason to not tag the release
> candidates as well? I like to see tags for any code that would be
> packaged and available to download. For instance, if I am trying to
> debug something in RC1, it's nice to be sure what code I'm testing.
>
> I agree about not branching until necessary, and really only on final
> releases.
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>>>ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
>>>permitting radical change for the 3.0 revision.
>>
>>I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
>>it if I have to. Basically I'd suggest that we form a release/2.1
>>directory off the base directory that contains all the necessary files
>>to build a 2.1 release. This will allow bugfixing on that release.
>
>
> I'll do this.
> I'll tag 2.1 when the final code is checked out for the release, then if we need to mess around with it later we can branch CVS then (and only then)
Was it discussed and/or is there a reason to not tag the release
candidates as well? I like to see tags for any code that would be
packaged and available to download. For instance, if I am trying to
debug something in RC1, it's nice to be sure what code I'm testing.
I agree about not branching until necessary, and really only on final
releases.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Danny Angus <da...@apache.org>.
> > iii) Add FetchPOP documentation
>
> I'd really like someone to contribute on this one. Volunteers?
You mean me don't yuo ;)
I'll do it.
> > i) Build a milestone build for testing.
We also need to test the source distribution to make sure it builds..
> > ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> > permitting radical change for the 3.0 revision.
>
> I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
> it if I have to. Basically I'd suggest that we form a release/2.1
> directory off the base directory that contains all the necessary files
> to build a 2.1 release. This will allow bugfixing on that release.
I'll do this.
I'll tag 2.1 when the final code is checked out for the release, then if we need to mess around with it later we can branch CVS then (and only then)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>