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.
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] > > > > >
