Whether you're incrementing the last number by one or labeling it RC, you
end up with a new release regardless. I don't have an issue with burning
numbers at all; it's out there for people to consume immediately no matter
what you call it. IMO, if anyone is concerned with the quality, either vote
it down or the RM should ask for Alpha/Beta/GA qualities in the voting
thread.




Cheers,
Paul

On Sun, Nov 15, 2015 at 2:13 PM, Benson Margulies <[email protected]>
wrote:

> On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict <[email protected]>
> wrote:
> > That's how it use to work, but that requires a double voting process:
> vote
> > once on the RC and then again if the RC is ready for production. It's
> > easier to just burn the numbers; if it fails, move to the next; otherwise
> > you release what you have.
>
> There's an advantage that I think you might be missing. When you vote
> an RC, it becomes a formal release, and you can advertise it to the
> user community for testing, which might get you more testers than you
> get on the dev@ list.
>
>
> >
> >
> > Cheers,
> > Paul
> >
> > On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar <[email protected]>
> wrote:
> >
> >> That's how Maven core releases were done in the early v3.0.x days.
> >> Personally I think it worked very good.
> >>
> >> /Anders (mobile)
> >> On Nov 15, 2015 15:40, "Benson Margulies" <[email protected]>
> wrote:
> >>
> >> > Given the number of 'burned' releases recently, I thought people might
> >> > be interested in hearing about an alternative approach.
> >> >
> >> > When a Lucene dev has a sudden urge to make a release, he or she set
> >> > up a release with a version of x.y.z-RC1. This is a real release. It
> >> > goes up for a vote.
> >> >
> >> > If there's something grossly wrong with it, the RM burns it and tries
> >> > again with RC2, etc.
> >> >
> >> > If it passes the vote, the user community (not just the dev community)
> >> > is invited/exhorted to test it for a bit. Problems are repaired. If
> >> > the fixes are significant, then the the next step is another RC. When
> >> > an RC is clean, or manifests only tiny problems, the RM goes ahead and
> >> > puts up x.y.z for a vote.
> >> >
> >> > The result of this is that a non-RC release hardly every gets burned.
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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]
>
>

Reply via email to