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
