I think this particular release is the oddball with the changes being so pervasive and taking so long. 2.0.9 went through the RCs in just a few weeks. I don't think we need betas on point releases...really only on things leading up to the .0 release.
-----Original Message----- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Saturday, August 23, 2008 12:03 AM To: Maven Developers List Subject: Re: RC release proposal -> Point releases + Beta quality I'm willing to try anything once, basically. I think we've had better success with the release candidate approach than anything else to date, but if we could find a way to make sure the odd point revision releases could get the same attention, I think it'd be fine. Maybe others will disagree, but I believe it's the psychology of thinking we're actively chasing the next release that keeps people looking at these release candidates. I'd just be afraid that having a solid version number - 2.0.11.1, say - lulls people into thinking it's a done deal until the next push-for-release. Maybe that's silly, I don't know, but I'm very interested in having a predictable process that keeps people engaged as we try to perfect the next release. Obviously, if the tests were better, this wouldn't be as big an issue, since there would be less likelihood of having so many problems crop up, and therefore needing so many RCs. I know that doesn't need pointing out, but there it is... -j Paul Benedict wrote: > John, > > Good response. > > I am still interested in finding a way of spacing the release > candidates out. What would you think of if 2.0.10 was voted as beta, > and then 2.0.11 would take the place of RC1-RC10 build list. Once the > 2.0.11 regression issues come in and are fixed, then you would have a > nice GA product. This is, in a way, similar to the odd-even release > versioning scheme. > > Paul > > On Fri, Aug 22, 2008 at 9:51 PM, John Casey <[EMAIL PROTECTED]> wrote: >> I have different experiences from past releases of the Maven project. If an >> issue comes up during a release vote, for instance, that brings up a very >> valid point of whether it's really kosher to fix it and continue the vote. >> Most people would say - and this is the general agreement in Maven, I think >> - that you're voting on a binary. This is why we've moved toward staging, >> then promoting, a proposed releasable binary. >> >> Obviously, it's not great to have 10 release candidates before a release. I >> don't doubt that there's been significant burnout among the development >> community WRT testing each successive RC in what is starting to seem like an >> endless stream. However, it's been our experience in the past that alpha >> releases don't get much attention, and beta releases take too much of the >> pressure off to getting a final release out the door. >> >> This is the second release that we've attempted the release candidate >> approach, and what I've noticed is that when you get beyond the first three >> or four issues discovered for that RC - not great, I know - the testing >> effort drops off significantly. I'm forced to conclude it's the level of >> effort, since there are issues cropping up that have been in several release >> candidates now. I know, it's definitely possible that people have a hard >> time keeping up with the velocity of these RCs. But in a way, that's a good >> thing, because when they do have time to try it out, they're working with >> the latest and greatest that we have to offer...so as not to trip up on >> different permutations of the same bug. >> >> I think there are definite downsides to all of these approaches, but I've >> found the level of engagement with these last two releases to be >> unprecedented since the 2.0 release. >> >> -john >> >> Paul Benedict wrote: >>> I would like to mention that Niall Pemberton, owner of Common >>> Beanutils, had a very good experience doing the latest builds using >>> RC. Each time he published an RC, he waited about 4-6 weeks to collect >>> feedback, patched those bugs, and released the next RC. >>> >>> Are shotgun release candidates too hurtful with the growing number of >>> iterations? Do we need a new RC per 2-3 issues, or should they be >>> "released" as "beta" and then revoted on for GA quality a couple weeks >>> -- or even one week -- later based on community feedback. >>> >>> I am thinking that if Maven moved to voting their RC builds as true >>> releases (yes, publishing to central repo), the iterative development >>> would be accepted better, and the public would be more involved. I >>> recommend turning each RC into a point release. >>> >>> Paul >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> -- >> John Casey >> Developer, PMC Member - Apache Maven (http://maven.apache.org) >> Blog: http://www.ejlife.net/blogs/buildchimp/ >> >> --------------------------------------------------------------------- >> 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] > -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ --------------------------------------------------------------------- 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]
