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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
