|
»
»
« Return to Thread: Fwd: What do we need to establish?
Re: What do we need to establish?
by James William Dumay
::
Rate this Message:
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@...> 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@...> 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@...> 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@...> 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
>
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@...> 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@...> 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@...> 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@...> 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
>
« Return to Thread: Fwd: What do we need to establish?
| Free embeddable forum powered by Nabble | Forum Help |
