archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James William Dumay <ja...@atlassian.com>
Subject Re: What do we need to establish?
Date Sat, 10 May 2008 06:21:13 GMT

On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:

> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@apache.org>  
> wrote:
>
>> This is what we currently have:
>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>
>> It's basically adopted from Maven's release procedure.
>> Does anyone think the 72 hrs. voting time is not enough for testing  
>> the
>> release? Or there's something wrong with the ordering of the  
>> process that we
>> have now? Thoughts, anyone? :-)
>
> 72 hours is the minimum, the RM can decide to wait longer (especially
> if someone asks for more time.)  The process will evolve, I'm not
> concerned with getting every step exactly right, as long as the end
> result is the same.

+1

>
>
> I'd like to see an announcement a couple of days prior to the tag.
> Nothing formal, essentially what James did, letting us know he's
> planning on a release this weekend.  A tag should not be a surprise to
> anyone who is watching the dev list.

+1

>
>
> I'd also like to discuss versioning.  I"m not a fan of baking the
> quality into the version number (as 1.1-beta-1).  My preference is
> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
> doesn't pass a vote, we discard it and move on.  Quality is determined
> after the release distribution exists, during the vote. (This is the
> httpd/Tomcat/Struts style of releasing.)

Thats an interesting point Wendy. With Confluence we decided that most  
of the versioning should not be done, as you said, with baking in the  
relative quality of the release but  on the progress of the final  
product.

I think the idea is that released versions encourage our more involved  
users into trying out incremental builds so we can catch problems  
before the final.

I would be in favor of having more frequent releases of trunk once  
certain milestones are met. Users who test those builds will then know  
exactly what changes they are in for.

>
>
> -- 
> Wendy


On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:

> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@apache.org>  
> wrote:
>
>> This is what we currently have:
>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>
>> It's basically adopted from Maven's release procedure.
>> Does anyone think the 72 hrs. voting time is not enough for testing  
>> the
>> release? Or there's something wrong with the ordering of the  
>> process that we
>> have now? Thoughts, anyone? :-)
>
> 72 hours is the minimum, the RM can decide to wait longer (especially
> if someone asks for more time.)  The process will evolve, I'm not
> concerned with getting every step exactly right, as long as the end
> result is the same.

+1

>
>
> I'd like to see an announcement a couple of days prior to the tag.
> Nothing formal, essentially what James did, letting us know he's
> planning on a release this weekend.  A tag should not be a surprise to
> anyone who is watching the dev list.

+1

>
>
> I'd also like to discuss versioning.  I"m not a fan of baking the
> quality into the version number (as 1.1-beta-1).  My preference is
> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
> doesn't pass a vote, we discard it and move on.  Quality is determined
> after the release distribution exists, during the vote. (This is the
> httpd/Tomcat/Struts style of releasing.)

Thats an interesting point Wendy. With Confluence we decided that most  
of the versioning should not be done, as you said, with baking in the  
relative quality of the release but  on the progress of the final  
product.

I think the idea is that released versions encourage our more involved  
users into trying out incremental builds so we can catch problems  
before the final.

I would be in favor of having more frequent releases of trunk once  
certain milestones are met. Users who test those builds will then know  
exactly what changes they are in for.

>
>
> -- 
> Wendy


Mime
View raw message