You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Rahul Akolkar <ra...@gmail.com> on 2007/01/09 19:20:09 UTC
Mirror v104? (was: RESULT ...)
On 1/9/07, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
>
> Pending 24 hours for reporting any errors in counting etc., I plan to
> complete the release tasks:
>
> * Copy the m2 artifacts and the metadata files over to the m2-rsync repo
> * Copy the release artifacts (*.zip), readme to the /www/wao/dist space
<snap/>
Should have stressed on the above bullet. v103 posted release
artifacts in the people.apache.org/dist space [1], whereas doing the
above for v104 will actually cause the release to be mirrored.
So, true or false: v104 should be mirrored.
-Rahul
[1] http://people.apache.org/dist/shale/v1.0.3/
> * Roll version numbers in 1_0_X branch
> * Sync up 1_0_X branch and trunk (except the 1.1 new features, ofcourse)
>
> Thanks for your time, all.
>
> -Rahul
>
Re: Mirror v104? (was: RESULT ...)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/11/07, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> 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.
>
<snap/>
OK, I'll post the proposed text for the announcement early next week
and we can send it out then (by that time the site will have been
updated, artifacts sufficiently mirrored etc.)
-Rahul
>
> Craig
>
Summarized release process (was: Re: Mirror v104? (was: RESULT ...))
Posted by Paul Spencer <pa...@apache.org>.
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 <ni...@gmail.com> wrote:
>>
>> On 1/12/07, Rahul Akolkar <ra...@gmail.com> wrote:
>> > This ones thoroughly OT, sorry list.
>> >
>> > On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
>> > > On 1/11/07, Rahul Akolkar <ra...@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
>> > > >
>> >
>>
>
Re: Mirror v104? (was: RESULT ...)
Posted by Craig McClanahan <cr...@apache.org>.
On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 1/12/07, Rahul Akolkar <ra...@gmail.com> wrote:
> > This ones thoroughly OT, sorry list.
> >
> > On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
> > > On 1/11/07, Rahul Akolkar <ra...@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
> > > >
> >
>
Re: Mirror v104? (was: RESULT ...)
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/12/07, Rahul Akolkar <ra...@gmail.com> wrote:
> This ones thoroughly OT, sorry list.
>
> On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
> > On 1/11/07, Rahul Akolkar <ra...@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
Niall
> -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
> > >
>
Re: Mirror v104? (was: RESULT ...)
Posted by Rahul Akolkar <ra...@gmail.com>.
This ones thoroughly OT, sorry list.
On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 1/11/07, Rahul Akolkar <ra...@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).
-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
> >
Re: Mirror v104? (was: RESULT ...)
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/11/07, Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
> <snip/>
> >
> > Struts posts a test build for a couple of weeks and then votes on the
> > release and quality at the same time. If theres alot of change then
> > the release might get voted initially as apha or beta. Once the
> > release has been out there a while and there are no apparent problems
> > we can vote again to upgrade the quality. It hasn't typically happened
> > this way though because it has usually taken cutting several releaes
> > before getting one without issues - so by the time we've voted a GA
> > release theres often been at least a couple of betas before that.
> >
> <snap/>
>
> 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.
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
>
>
> > Niall
Re: Mirror v104? (was: RESULT ...)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/11/07, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> Struts posts a test build for a couple of weeks and then votes on the
> release and quality at the same time. If theres alot of change then
> the release might get voted initially as apha or beta. Once the
> release has been out there a while and there are no apparent problems
> we can vote again to upgrade the quality. It hasn't typically happened
> this way though because it has usually taken cutting several releaes
> before getting one without issues - so by the time we've voted a GA
> release theres often been at least a couple of betas before that.
>
<snap/>
Here is the relevant recent example I mentioned in the last post ( [1]
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
> Niall
>
Re: Mirror v104? (was: RESULT ...)
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/10/07, Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/9/07, Niall Pemberton <ni...@gmail.com> wrote:
> > The thing I think is confusing is that you didn't vote on a "quality"
> > - as I understand you're thinking of having different quality grades
> > for different components because of tiles(?) Anyway whatever the
> > process you're using for quality IMO it would be better to determine
> > this before announcing the release - as I'm sure people will either
> > assume its GA quality or wonder what its designation is (alpha, beta,
> > GA).
> >
> <snap/>
>
> Correct, the announcement is not even on my todo list yet ;-) My
> understanding is (from observing tomcat, think struts does similarly)
> that the quality vote usually follows in a couple of weeks after the
> release vote, followed by the announcement. Wendy was, I think (IIRC
> and all other disclaimers included), proposing that release vote come
> with a proposed "default" quality but I didn't hear anything after
> that (and was not the case with v1.0.4 either).
Struts posts a test build for a couple of weeks and then votes on the
release and quality at the same time. If theres alot of change then
the release might get voted initially as apha or beta. Once the
release has been out there a while and there are no apparent problems
we can vote again to upgrade the quality. It hasn't typically happened
this way though because it has usually taken cutting several releaes
before getting one without issues - so by the time we've voted a GA
release theres often been at least a couple of betas before that.
Niall
> -Rahul
>
>
> > Niall
> >
>
Re: Mirror v104? (was: RESULT ...)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/9/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 1/9/07, Rahul Akolkar <ra...@gmail.com> wrote:
> > On 1/9/07, Rahul Akolkar <ra...@gmail.com> wrote:
> > <snip/>
> > >
> > > Pending 24 hours for reporting any errors in counting etc., I plan to
> > > complete the release tasks:
> > >
> > > * Copy the m2 artifacts and the metadata files over to the m2-rsync repo
> > > * Copy the release artifacts (*.zip), readme to the /www/wao/dist space
> > <snap/>
> >
> > Should have stressed on the above bullet. v103 posted release
> > artifacts in the people.apache.org/dist space [1], whereas doing the
> > above for v104 will actually cause the release to be mirrored.
> >
> > So, true or false: v104 should be mirrored.
>
> Since this is an official Apache release authorised by the Shale PMC
> then it can (and should IMO) be distributed in the official (mirrored)
> repositories.
>
<snip/>
Yup, my understanding also. What led me to pause (and question) is the
fact that the dist space [1] is empty ATM.
I plan on creating two directories in that space:
* framework/
* apps/
filled with the corresponding 1.0.4 artifacts and with "current"
symlinks at the top level (dist/shale/)
[1] http://www.apache.org/dist/shale/
(more below ...)
> The thing I think is confusing is that you didn't vote on a "quality"
> - as I understand you're thinking of having different quality grades
> for different components because of tiles(?) Anyway whatever the
> process you're using for quality IMO it would be better to determine
> this before announcing the release - as I'm sure people will either
> assume its GA quality or wonder what its designation is (alpha, beta,
> GA).
>
<snap/>
Correct, the announcement is not even on my todo list yet ;-) My
understanding is (from observing tomcat, think struts does similarly)
that the quality vote usually follows in a couple of weeks after the
release vote, followed by the announcement. Wendy was, I think (IIRC
and all other disclaimers included), proposing that release vote come
with a proposed "default" quality but I didn't hear anything after
that (and was not the case with v1.0.4 either).
-Rahul
> Niall
>
Re: Mirror v104? (was: RESULT ...)
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/9/07, Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/9/07, Rahul Akolkar <ra...@gmail.com> wrote:
> <snip/>
> >
> > Pending 24 hours for reporting any errors in counting etc., I plan to
> > complete the release tasks:
> >
> > * Copy the m2 artifacts and the metadata files over to the m2-rsync repo
> > * Copy the release artifacts (*.zip), readme to the /www/wao/dist space
> <snap/>
>
> Should have stressed on the above bullet. v103 posted release
> artifacts in the people.apache.org/dist space [1], whereas doing the
> above for v104 will actually cause the release to be mirrored.
>
> So, true or false: v104 should be mirrored.
Since this is an official Apache release authorised by the Shale PMC
then it can (and should IMO) be distributed in the official (mirrored)
repositories.
The thing I think is confusing is that you didn't vote on a "quality"
- as I understand you're thinking of having different quality grades
for different components because of tiles(?) Anyway whatever the
process you're using for quality IMO it would be better to determine
this before announcing the release - as I'm sure people will either
assume its GA quality or wonder what its designation is (alpha, beta,
GA).
Niall
> -Rahul
>
> [1] http://people.apache.org/dist/shale/v1.0.3/
>
>
> > * Roll version numbers in 1_0_X branch
> > * Sync up 1_0_X branch and trunk (except the 1.1 new features, ofcourse)
> >
> > Thanks for your time, all.
> >
> > -Rahul