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:38:03 GMT
Forgot to add: I propose that the next release of Archiva will be 1.1- 
milestone1. As each major feature is completed, we increment that  
number and the last milestone becomes 1.1.0.

James

On 10/05/2008, at 4:21 PM, James William Dumay wrote:

>
> 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
>

Forgot to add: I propose that the next release of Archiva will be 1.1- 
milestone1. As each major feature is completed, we increment that  
number and the last milestone becomes 1.1.0.

James

On 10/05/2008, at 4:21 PM, James William Dumay wrote:

>
> 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