shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <pau...@apache.org>
Subject Summarized release process (was: Re: Mirror v104? (was: RESULT ...))
Date Fri, 12 Jan 2007 18:15:28 GMT
Below is my understanding on the general release process

***
* Initial release
***
1) A proposed release is staged

2) Upon acceptance, via a vote, the following occurs:
o Source is tagged.
o Site is updated to include distribution with a notation if it's status
o Maven repositories are updated.
o Announcement posted on developer mailing list.

***
* Status upgrade
***
1) Upon acceptance, via a vote, to upgrade the status the following
occurs:
o Site is updated to reflect the status change.
o An announcement is posted on the developer mailing list.
o For "stable" status, announcements are posted on the mailing list that 
are sent to the user community, i.e. user@shale.apache.org, 
announce@shale.apache.org, .....
o No change will be made to the distribution or maven repository.

***
* Other notes
***
1) Once a distribution is release, a new distribution will NOT be 
generated for the same version.  i.e. when 1.0.4 goes from beta to 
stable no new distribution will be generated.

2) If a status upgrade is not accepted, the version number will NOT be 
reused.  i.e. if  1.0.4 does not make stable then their will never be a 
1.0.4 stable version.

3) Their can be many releases active at one time.  i.e. 1.0.4 can be 
going through the beta to stable upgrade process while 1.0.5 is being
release as an alpha.

4) A release can be patched, but it will get a new version number when 
released.

5) The chart below is a mock up of several release.
         -------- Release Status -----------
Version   Alpha      Beta        Stable
------- ----------- ----------- -----------
1.0.2    1-nov-2006 *rejected*
1.0.2.1 10-nov-2006 20-nov-2006  1-dec-2006
1.0.3    1-dec-2006 10-dec-2006 20-dec-2006
1.0.4    1-jan-2007 15-jan-2007
1.0.5   14-jan-2007

Paul Spencer


Craig McClanahan wrote:
> On 1/11/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>>
>> On 1/12/07, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> > This ones thoroughly OT, sorry list.
>> >
>> > On 1/11/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>> > > On 1/11/07, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> > <snip/>
>> > > >
>> > > > Here is the relevant recent example I mentioned in the last post (
>> [1]
>> > >
>> > > The quality grade in that initial post is in the title "[VOTE] 
>> Release
>> > > build 6.0.7 as alpha" - so they are doing the same as Struts - voting
>> > > on an initial release as "alpha" quality. I assume the second post is
>> > > then a vote to either keep it as alpha or upgrade it to beta.
>> > >
>> > <snap/>
>> >
>> > Indeed, got that. And the two reasons you state [A] where voting twice
>> > is not necessary also make good sense. But, is the above the same as
>> > the Struts process ATM? I seem to remember a 2.0.1 quality vote and
>> > now talk of 2.0.3, but no vote at all for 2.0.2 (I may have just
>> > missed it, if so, sorry).
>>
>> AFAIK 2.0.2 was only ever a test build and not a release. I haven't
>> followed s2 too closely but I believe the fact that it depended on
>> unreleased XWork meant that it was never going to go GA - so the plan
>> changed to getting xwork out and then doing a 2.0.3
> 
> 
> Sorry for not responding on this thread earlier ... was heads down on some
> day job stuff.
> 
> The way I understand the "Struts Way" (and the "Tomcat Way" and so on) is
> that a release can be distributed (on the mirrors etc) and announced as 
> soon
> as the vote pases.  What we weren't clear (with ourselves and others) on 
> for
> 1.0.4 is that it should probably be announced with a "default" stability
> grade of alpha that might get upgraded later based on experience.  I've 
> seen
> "we hope to see this release's stability grade gets upgraded" type 
> comments,
> and it seems appropriate to me -- if for no other reason than to encourage
> people to give us feedback to help make that decision.
> 
> Niall
> 
> 
> Craig
> 
> 
>> -Rahul
>> >
>> > [A]
>> http://www.nabble.com/Re%3A-Why-vote-twice-for-a-release-quality--p4246751.html 
>>
>> >
>> >
>> > > Niall
>> > >
>> > > > followed by [2] in a couple of weeks ) from tomcat's (recently
>> > > > improved) process. If and when I RM another Shale release, it will
>> > > > come with a quality marker to begin with (might as well be alpha,
>> but
>> > > > mentioned explicitly). I prefer a release vote over a test build
>> (that
>> > > > was not voted on).
>> > > >
>> > > > In any case, let me get back to completing the v1.0.4 release 
>> tasks.
>> > > > Many thanks for your input.
>> > > >
>> > > > -Rahul
>> > >
>> > > > [1] 
>> http://marc.theaimsgroup.com/?l=tomcat-dev&m=116695917620851&w=2
>> > > > [2] 
>> http://marc.theaimsgroup.com/?l=tomcat-dev&m=116801203312451&w=2
>> > > >
>> >
>>
> 


Mime
View raw message