Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:54:35 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 22:39:44 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 20 Oct 2004 01:28:29 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 20:47:56 -0700, Martin Cooper wrote: When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. I believe the initial suggestion, way back when, was to use the HTTPD protocol, which people then mentioned was like the Tomcat protocol. I don't believe that's correct. Craig brought up the topic, from his experience with Tomcat, and specifically suggested that we do things the way Tomcat was doing them. I did indeed propose the Tomcat model, or at least the Tomcat model that I understood to be working at the time. More recently, it looks like there's an informal step of tacit agreement on the dev list that a new release should be created, with an implicit alpha quality rating. I don't care if we go with implicit alpha ratings versus no rating at all -- indeed that probably makes more sense. The issue to me is that people on the user@ or announcements@ lists (i.e. those who have not been subjected to this thread ;) will not read past the Alpha or Beta in the subject line to get to the Build versus Release distinction. That distinction is very important, because it is the difference between something that has been voted on by the PMC and something that has not (or rather, vice versa, respectively). Grouping Alpha, Beta and GA as Release designations only, and calling anything not voted on a Test Build makes it crystal clear. -- Martin Cooper I do care if, for example, I can go create a Struts-Faces Integration Library 1.0.1 release (even if it's labelled as alpha quality) with zero input from the other committers. That doesn't seem like something we want to encourage. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. The Apache HTTPD team prejudges their builds as Alpha. http://httpd.apache.org/dev/release.html Each of us vote when a commit is made, even if it is a lazy vote. AFAIK, the ASF Board has never, ever defined what does and does not require a vote. They've delegated that decision to the Struts Vice President and PMC. Something requires a vote if we say it requires a vote. Likewise for not requiring a vote. IMHO, people are applying shades of meaning to the words release, build, and distribution, that are unintended by the Foundation and elude our users. The operative words are automated or nightly and Alpha, Beta, and General Release. There is no point in reinventing terminology that other teams -- well experienced in the art and science of creating releases -- have already clearly defined. Again, here's my +1 for adopting the HTTPD release protocol, with the one modification of using the term Alpha build in lieu of Alpha release. -Ted. On Mon, 18 Oct 2004 22:59:48 -0700, Martin Cooper wrote: On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush [EMAIL PROTECTED] wrote: When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/18/2004 6:39:44 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Touche, Martin! A point well made! I believe I understand better now. Thanks :-) - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 12:59 AM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush [EMAIL PROTECTED] wrote: When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/18/2004 6:39:44 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/19/2004 5:55:32 AM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. This is something which seems entirely contrary to the spirit of these frequent, incremental builds -- I have assumed all along that the point was that when a build was first made, it would be, no matter what considered of alpha quality, and that after the build was in the wild for a while and real feedback came in, we would use that feedback to upgrade the status of the build when appropriate. I strongly disagree with the idea that we look bad when we upgrade a release. I do think we look bad if we downgrade. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Semantics and terms aside, there is a key difference between the approaches being discussed: (a) In the HTTPD way, the release manager can post a release (prejudged to be alpha quality) with a formal version number, with no vote from the rest of the PMC. (b) In the Tomcat way, the release manager can post a test build (essentially a release *candidate*) that still needs to be voted on to be actually released. Approach (a) seems to be what bothers Martin, and I'm uncomfortable with it as well. It works as long as you don't have any RMs with delusions of grandeur, trying to be dictatorial about where a project heads -- we haven't had that problem, but why make it possible? Approach (b) requires a positive action on the part of the PMC to do anything more than a test build, and gives the community of users a sense that we're all behind this release. Terminology isn't the important part to me -- voting is. That's why I prefer approach (b). Craig On Tue, 19 Oct 2004 04:32:30 -0400, Ted Husted [EMAIL PROTECTED] wrote: A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. The Apache HTTPD team prejudges their builds as Alpha. http://httpd.apache.org/dev/release.html Each of us vote when a commit is made, even if it is a lazy vote. AFAIK, the ASF Board has never, ever defined what does and does not require a vote. They've delegated that decision to the Struts Vice President and PMC. Something requires a vote if we say it requires a vote. Likewise for not requiring a vote. IMHO, people are applying shades of meaning to the words release, build, and distribution, that are unintended by the Foundation and elude our users. The operative words are automated or nightly and Alpha, Beta, and General Release. There is no point in reinventing terminology that other teams -- well experienced in the art and science of creating releases -- have already clearly defined. Again, here's my +1 for adopting the HTTPD release protocol, with the one modification of using the term Alpha build in lieu of Alpha release. -Ted. On Mon, 18 Oct 2004 22:59:48 -0700, Martin Cooper wrote: On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush [EMAIL PROTECTED] wrote: When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 04:32:30 -0400, Ted Husted wrote: Again, here's my +1 for adopting the HTTPD release protocol, with the one modification of using the term Alpha build in lieu of Alpha release. Or, we could even go the whole nine yards and use use Test Build in lieu of Alpha Release, so the three grades would be * Test Build * Beta Release * General Availability Release Assuming that this is something everyone can agree upon, I'll update the Release Guidelines and ByLaws to use these terms consistently. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Actually, I think what everyone's getting at is that you should evaluate and then label. Labeling right off the bat makes it look like the system is arbitrary - even if it is well defined that we start at alpha then move up. It would certainly look worse to downgrade than upgrade our rating, but I do see Martin's point. OpenSource is really growing tons. People are still scared of it though. You can try and explain that commercial packages routinely distribute packages for GA that would never make beta in the OpenSource community -- simply to gain some return from their product -- but ti really doesn't help :-| By making the system seem less arbitrary, we raise our level of credibility. That seems like a worthy method to me :-) Measure twice; cut once. Eddie - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 8:02 AM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. This is something which seems entirely contrary to the spirit of these frequent, incremental builds -- I have assumed all along that the point was that when a build was first made, it would be, no matter what considered of alpha quality, and that after the build was in the wild for a while and real feedback came in, we would use that feedback to upgrade the status of the build when appropriate. I strongly disagree with the idea that we look bad when we upgrade a release. I do think we look bad if we downgrade. Joe -- Joe Germuska[EMAIL PROTECTED] http://blog.germuska.comIn fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0443-0, 10/19/2004 Tested on: 10/19/2004 6:26:57 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 10:00:42 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Semantics and terms aside, there is a key difference between the approaches being discussed: (a) In the HTTPD way, the release manager can post a release (prejudged to be alpha quality) with a formal version number, with no vote from the rest of the PMC. (b) In the Tomcat way, the release manager can post a test build (essentially a release *candidate*) that still needs to be voted on to be actually released. Approach (a) seems to be what bothers Martin, and I'm uncomfortable with it as well. It works as long as you don't have any RMs with delusions of grandeur, trying to be dictatorial about where a project heads -- we haven't had that problem, but why make it possible? Approach (b) requires a positive action on the part of the PMC to do anything more than a test build, and gives the community of users a sense that we're all behind this release. Terminology isn't the important part to me -- voting is. That's why I prefer approach (b). +1. You hit the nail on the head with respect to voting being the key. I do think that the terminology is important, though, in the sense that we need to be clear in communicating with our users / customers. And I think the Tomcat terminology is very clear. When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. -- Martin Cooper Craig On Tue, 19 Oct 2004 04:32:30 -0400, Ted Husted [EMAIL PROTECTED] wrote: A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. The Apache HTTPD team prejudges their builds as Alpha. http://httpd.apache.org/dev/release.html Each of us vote when a commit is made, even if it is a lazy vote. AFAIK, the ASF Board has never, ever defined what does and does not require a vote. They've delegated that decision to the Struts Vice President and PMC. Something requires a vote if we say it requires a vote. Likewise for not requiring a vote. IMHO, people are applying shades of meaning to the words release, build, and distribution, that are unintended by the Foundation and elude our users. The operative words are automated or nightly and Alpha, Beta, and General Release. There is no point in reinventing terminology that other teams -- well experienced in the art and science of creating releases -- have already clearly defined. Again, here's my +1 for adopting the HTTPD release protocol, with the one modification of using the term Alpha build in lieu of Alpha release. -Ted. On Mon, 18 Oct 2004 22:59:48 -0700, Martin Cooper wrote: On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush [EMAIL PROTECTED] wrote: When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/18/2004 6:39:44 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com -- --- To unsubscribe, e-mail: dev- [EMAIL PROTECTED] For additional commands, e- mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/18/2004 6:39:44 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com -- --- To unsubscribe, e-mail: dev- [EMAIL PROTECTED] For additional commands, e- mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
From an innocent bystander... For what it's worth, based on my experience following the Tomcat developer list, it pretty much works exactly as the HTTPD description below (a). To back it up, here's the quote fromt he latest release vote: Hi, Tomcat 5.5.3 has been available for about a week now, so it's time for a stability vote. I tentatively rated it Alpha when releasing as my own personal impression, but I haven't had any significant issues with it myself. It passes our internal tests, and with the StandardWrapper hotfix it passes the Servlet and JSP TCKs. So: Tomcat 5.5.3 should be rated: [ ] Alpha still, because ??? [ ] Beta, it's getting closer to stable [what's missing?] [ ] Stable, it's rock solid ...and so on... Note the presumed alpha. Based on discussions, it pretty much seemed like Tomcat adopted the HTTPD way wholesale. I read a lot of e-mail and my memory could be fuzzy though. Of course, that doesn't mean struts couldn't just do its own thing anyway. Just trying to avoid confusion. -Paul Ted Husted wrote: Terminology isn't the important part to me -- voting is. That's why I prefer approach (b). I believe assigning a milestone number to a distribution and tagging the repository with that number promotes voting. The vote can be on a precise entity: what is tagged in the repository for the given milestone and represented by the distribution. It might be helpful to adopt the convention of adding an ALPHA marker to new milestones. A distribution file name could start out in the form struts_1_2_5_ALPHA.zip. An alpha marker in the file name would make it very clear that this is not a formal distribution. If the milestone is voted to Beta or General Availability, then we could drop the ALPHA marker, and if appropriate, submit the Beta or General Availability distribution for mirroring. The solution for dictatorial release managers is to prevent the position from being institutionalized. IMHO, a new rule should be that the first thing a new Committer must do is roll the next milestone :) So long as any of us can roll a milestone release, then the PMC will always be able to vote on whatever milestone it deems worthy. The board has made it very clear that all protected code must be in an Apache repository, and we all have a vote as to what goes into the repository. I like the HTTPD protocol because it is clean and effective. We roll the distribution, tag the repository, and (essentially) vote on the tag. The process is unambiguous and repository-driven. If we want safeguards, then let's put alpha in the name of a new-born milestone, and make sure the release process is something any one of us can initiate. -Ted. On Tue, 19 Oct 2004 10:00:42 -0700, Craig McClanahan wrote: Semantics and terms aside, there is a key difference between the approaches being discussed: (a) In the HTTPD way, the release manager can post a release (prejudged to be alpha quality) with a formal version number, with no vote from the rest of the PMC. (b) In the Tomcat way, the release manager can post a test build (essentially a release *candidate*) that still needs to be voted on to be actually released. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 20:47:56 -0700, Martin Cooper wrote: When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. I believe the initial suggestion, way back when, was to use the HTTPD protocol, which people then mentioned was like the Tomcat protocol. I have always thought we were using HTTPD protocol, which is why they are incorporated by reference on the Release Guide page. The HTTP protocol is also what is described by the ByLaws page. When I saw the terminology drifting, I thought it would be best to make a thread of it, to be sure we are all on the same page. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:13:51 -0700, Martin Cooper wrote: Do you have a particular objection to adopting the Tomcat scheme, which Craig and I, at least, prefer over the HTTPD scheme? Can't we just settle on the Tomcat scheme and move on? I've seen some casual descriptions of the Tomcat scheme, but, yes, I do prefer the protocol the HTTPD team uses. http://httpd.apache.org/dev/release.html Is there a link to the Tomcat scheme that we can use as a basis of comparison. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Wed, 20 Oct 2004 01:31:45 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 22:13:51 -0700, Martin Cooper wrote: Do you have a particular objection to adopting the Tomcat scheme, which Craig and I, at least, prefer over the HTTPD scheme? Can't we just settle on the Tomcat scheme and move on? I've seen some casual descriptions of the Tomcat scheme, but, yes, I do prefer the protocol the HTTPD team uses. I know you prefer it - I think that's fairly clear by now. ;-) What I asked was if you have a particular objection to adopting the Tomcat scheme, since both Craig and I have voiced a preference for that. http://httpd.apache.org/dev/release.html Is there a link to the Tomcat scheme that we can use as a basis of comparison. I don't know off the top of my head, but I'll certainly look for one. I can tell you that the 1.2.4 Test Build and Release messages were cribbed very directly from messages sent out for Tomcat releases. (BTW, I'm more than a little surprised at the amount of energy you're putting into this, Ted, given that you've told us all you're going Emeritus anyway, so that those of us remaining will be the folks rolling the releases. ;) -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Wed, 20 Oct 2004 01:28:29 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 20:47:56 -0700, Martin Cooper wrote: When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. I believe the initial suggestion, way back when, was to use the HTTPD protocol, which people then mentioned was like the Tomcat protocol. I don't believe that's correct. Craig brought up the topic, from his experience with Tomcat, and specifically suggested that we do things the way Tomcat was doing them. -- Martin Cooper I have always thought we were using HTTPD protocol, which is why they are incorporated by reference on the Release Guide page. The HTTP protocol is also what is described by the ByLaws page. When I saw the terminology drifting, I thought it would be best to make a thread of it, to be sure we are all on the same page. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:39:44 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 20 Oct 2004 01:28:29 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 20:47:56 -0700, Martin Cooper wrote: When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. I believe the initial suggestion, way back when, was to use the HTTPD protocol, which people then mentioned was like the Tomcat protocol. I don't believe that's correct. Craig brought up the topic, from his experience with Tomcat, and specifically suggested that we do things the way Tomcat was doing them. I did indeed propose the Tomcat model, or at least the Tomcat model that I understood to be working at the time. More recently, it looks like there's an informal step of tacit agreement on the dev list that a new release should be created, with an implicit alpha quality rating. I don't care if we go with implicit alpha ratings versus no rating at all -- indeed that probably makes more sense. I do care if, for example, I can go create a Struts-Faces Integration Library 1.0.1 release (even if it's labelled as alpha quality) with zero input from the other committers. That doesn't seem like something we want to encourage. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:38:15 -0700, Martin Cooper [EMAIL PROTECTED] wrote: (BTW, I'm more than a little surprised at the amount of energy you're putting into this, Ted, given that you've told us all you're going Emeritus anyway, so that those of us remaining will be the folks rolling the releases. ;) Shh!!! Don't let him think that's still an option!!! :-) Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Here's my +1 for adopting the HTTP server release process, with whatever modifications we deem necessary. I agree with this. I believe we should consider anything a release which has gone through the release checklist and had a version number assigned and a corresponding tag applied to SVN. This is a purely mechanical definition. Anything else might involve confusion if a version number were reused. I think only the promotion of a release from alpha should require a vote. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote: Here's my +1 for adopting the HTTP server release process, with whatever modifications we deem necessary. I agree with this. I believe we should consider anything a release which has gone through the release checklist and had a version number assigned and a corresponding tag applied to SVN. This is a purely mechanical definition. Anything else might involve confusion if a version number were reused. I disagree with the idea of calling anything a Release without voting on it. What led to our change in process was a desire to move to the Tomcat way of doing things. Mention of the HTTPD way of doing things came along later. The Tomcat way has us building Test Builds which we later vote on to decide if it's a Release of any sort. That is the process that I followed for 1.2.4, and that is the process that I want to see us adopt. It was actually my understanding that we had already done so, which is why I've been following it. If the HTTPD process is different from that, then I am -1 on adopting that process. -- Martin Cooper I think only the promotion of a release from alpha should require a vote. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
At 9:35 AM -0700 10/18/04, Martin Cooper wrote: On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote: Here's my +1 for adopting the HTTP server release process, with whatever modifications we deem necessary. I agree with this. I believe we should consider anything a release which has gone through the release checklist and had a version number assigned and a corresponding tag applied to SVN. This is a purely mechanical definition. Anything else might involve confusion if a version number were reused. I disagree with the idea of calling anything a Release without voting on it. What led to our change in process was a desire to move to the Tomcat way of doing things. Mention of the HTTPD way of doing things came along later. The Tomcat way has us building Test Builds which we later vote on to decide if it's a Release of any sort. That is the process that I followed for 1.2.4, and that is the process that I want to see us adopt. It was actually my understanding that we had already done so, which is why I've been following it. If the HTTPD process is different from that, then I am -1 on adopting that process. In my ignorance, I didn't even realize that there was that much difference between Tomcat's process and HTTPD's process. I would formalize my vote as +0 - I don't feel very strongly about it, and Martin apparently does. I had thought we were going to do it the way I described, but I don't really think much is lost by adding in a test build period. I do think there would be potential confusion if a test build was not voted as a release, but the amount of that potential confusion is probably pretty low if we're just talking about activity on the dev list. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Mon, 18 Oct 2004 12:13:10 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 9:35 AM -0700 10/18/04, Martin Cooper wrote: On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote: Here's my +1 for adopting the HTTP server release process, with whatever modifications we deem necessary. I agree with this. I believe we should consider anything a release which has gone through the release checklist and had a version number assigned and a corresponding tag applied to SVN. This is a purely mechanical definition. Anything else might involve confusion if a version number were reused. I disagree with the idea of calling anything a Release without voting on it. What led to our change in process was a desire to move to the Tomcat way of doing things. Mention of the HTTPD way of doing things came along later. The Tomcat way has us building Test Builds which we later vote on to decide if it's a Release of any sort. That is the process that I followed for 1.2.4, and that is the process that I want to see us adopt. It was actually my understanding that we had already done so, which is why I've been following it. If the HTTPD process is different from that, then I am -1 on adopting that process. In my ignorance, I didn't even realize that there was that much difference between Tomcat's process and HTTPD's process. I would formalize my vote as +0 - I don't feel very strongly about it, and Martin apparently does. I had thought we were going to do it the way I described, but I don't really think much is lost by adding in a test build period. I do think there would be potential confusion if a test build was not voted as a release, but the amount of that potential confusion is probably pretty low if we're just talking about activity on the dev list. The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. -- Martin Cooper Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
+1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Well, whatever you guys decide is fine with me. I don't care which path we take. I am just trying to help out when and where I can. Let me know if I need to change something (mail, wiki, whatever). -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 3:06 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
How about if we follow the HTTPD protocol but replace the term Alpha Release with Alpha Build and then refer to a distribution when we could be talking about a Alpha Build or Beta Release or GA Release. * http://httpd.apache.org/dev/release.html And, yes, I would agree that there should be one release protocol for the project, which all subprojects, including the core, would follow. -Ted. On Mon, 18 Oct 2004 12:25:32 -0700, Craig McClanahan wrote: +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0442-3, 10/15/2004 Tested on: 10/18/2004 6:39:44 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
