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]
