in lucene/testframework:renamed CheapBastard codec to Lucene54 to see if the SPILoader would pick it up ..it didnteven when i replaced CheapBastard entry in resources/META-INF/services/org.apache.lucene.codecs.Codeca quick refactor NamedSPILoader.lookup(String name) to read resources/META-INF/services/org.apache.lucene.codecs.Codec (and replace CheapBastard to Lucene54 in TestRuleSetupAndRestoreClassEnv)and now Lucene54 codec is picked up by NamedSPILoader lookup method
Maven Specific:
refactored the 10 year old ivy script reactor workflow which is difficult to
follow.. so I created pom.xml from original ivy build.xml
attaching test-framework pom.xml for review
(mentioned this to McCandless BTW..but havent heard back)
Merci!
Martin
______________________________________________
> Date: Sun, 15 Nov 2015 21:10:58 +0000
> Subject: Re: How the Lucene PMC manages releases
> From: stephen.alan.conno...@gmail.com
> To: dev@maven.apache.org
>
> 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
> > >
> > >
> >
pom.xml
Description: XML document
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
