Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Don Brown
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote: I won't cast a quality vote on anything but a tagged and rolled, downloadable distribution. Many of the problems we've had in the past (not just this time, but with other series too) appear in the final product and are not evident in a checkout.

Re: Wiki and User Guide

2006-05-17 Thread Ted Husted
Well, there is a link to the upgraders wiki page in the Release Notes, so it's incorporated by reference. I added a bullet to help emphasize the link. One reason the content on the updgrader pages is so useful is because it's easy for developers to update it. The other documenation is kept in

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Wendy Smoak
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1. Based on this and other comments, I'd like to add the following to the release guidelines [1]: * Versions with significant changes,

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Don Brown
On 5/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: I agree with Ted and Paul that we should only vote on the actual signed distribution that's going to be uploaded. It's easy to imagine accidentally introduce a problem when you're building the final distribution. I wouldn't be comfortable

Re: API updates and build fix...

2006-05-17 Thread Eric Molitor
The name changes resolve the ambiguities that I saw in the first draft so that is a definite positive. The Messages.Severity enum and other messaging improvements are a definite positive. (They satisfy my desire for a Log4J type usage but are still distinct enough to avoid confusion.) Since the

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Wendy Smoak
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote: Ok, so if you don't think this is the answer to the backwards release then test problem, what is? I don't know. Earlier 1.x releases had the benefit of the entire team focused on them, and more people using nightly builds. That's no longer the

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Ted Husted
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote: I'd guess 90+% of other open source projects seem to do just fine doing all the testing and voting before the release. I'm not aware of any project, open or closed source, that only issues stable or GA releases without issuing any type of beta or

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Craig McClanahan
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1 I think the notion that we can't announce and mirrors Betas is a misunderstanding. We can

Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)

2006-05-17 Thread Ted Husted
On 5/17/06, Craig McClanahan [EMAIL PROTECTED] wrote: Announce and mirror are two different things. IIRC, Apache's general guidelines on mirror are GA releases only (although we've probably been among the folks that bypassed that policy on occasion). The FAQ suggest that all releases be