Sounds good to me.. I just prefer the final version to 1.1 instead of 1.1.0 (i'm just being vain) :-)
-Deng On Sat, May 10, 2008 at 2:38 PM, James William Dumay <[EMAIL PROTECTED]> wrote: > 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 >>> >> >> >
