Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <2B87BBCA-E9B8-4031-A1C7-5CBD17D20C88@atlassian.com>
From: James William Dumay <james@atlassian.com>
To: dev@archiva.apache.org
In-Reply-To: <56B43F34-856F-4CD6-B50B-8B26D38B104A@atlassian.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v922)
Subject: Re: What do we need to establish?
Date: Sat, 10 May 2008 16:38:03 +1000
References: <1a57a2980805062304w592739b4s7cf911e0785d1e97@mail.gmail.com>
 <373C2239-E9F7-4A43-85EA-00348D04FC5A@apache.org>
 <1a57a2980805062350g46583093seb91a7bd79fd4766@mail.gmail.com>
 <1a57a2980805090119x2306d36ftfc66405d23bae30e@mail.gmail.com>
 <adba96190805090845y6d46f8e5n65def7cbc7c79ca1@mail.gmail.com>
 <56B43F34-856F-4CD6-B50B-8B26D38B104A@atlassian.com>

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
>