james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Benett <charl...@apache.org>
Subject Re: Release Plan v2.1 (update)
Date Tue, 26 Nov 2002 20:44:34 GMT
(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:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message