maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: RC release proposal -> Point releases + Beta quality
Date Sat, 23 Aug 2008 03:26:13 GMT
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 <jdcasey@commonjava.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message