To my thinking this is a case of special circumstances. I wrote a test case but didn't understand how to integrate the test case correctly into the suite and as such a regression crept in when fixing some regressions in other (non-covered) areas of the version inheritance code. I attribute at least 3 of the version numbers to the various regressions in this area of the code base. Thankfully we now have better tests in this area and they are now integrated.
Let's see how many numbers we end up burning next time around before we rush to change how we do things. On 15 November 2015 at 20:48, Paul Benedict <pbened...@apache.org> wrote: > 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 <bimargul...@gmail.com> > wrote: > > > On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict <pbened...@apache.org> > > 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 <and...@hammar.net> > > 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" <bimargul...@gmail.com> > > 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: dev-unsubscr...@maven.apache.org > > >> > For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > > >> > > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
