Backward incompatibility is something that should be considered as a blocker.
Anyway , I have fixed the issue in 4.7 branch. I have also fixed the SOLR-3854 omission You can respin a build On Sat, Feb 22, 2014 at 1:10 AM, Simon Willnauer <simon.willna...@gmail.com>wrote: > Thanks nobel! can you please ping me here so I can kick off another RC. > > Regarding the bugs that should / should not block a release I think > it's hard to say which one should and that is my biggest problem here. > I think with more frequent releases and more point releases we can > make the intervals shorter and bugs get fixed quicker. I think it's > also the responsibility of the other committers to maybe go back a > step and ask themself if a bug should block a release and only if the > are absolutely +1 on respin mention it on the release thread? To me as > a RM it's really hard to draw the line. I also think we should not > push stuff into the release branch unless it's the cause of the > respin, we should work towards a stable branch an every change makes > it less stable again IMO. > > just my $0.05 > > On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള് नोब्ळ् > <noble.p...@gmail.com> wrote: > > I'm working on a test case for 5762 I'll commit it tomorrow IST > > > > On 21 Feb 2014 20:05, "Simon Willnauer" <simon.willna...@gmail.com> > wrote: > >> > >> So the problem here is where to draw the line. I think in a setup like > >> we have with lucene and solr in one codebase the chance to hit a bug > >> within these 72h is huge. This means the Release process is a huge > >> pain each time. Then we have bugs that justify a respin and some who > >> don't. I looked at SOLR-5762 and it seems this one should cause a > >> respin but the LUCENE-5461 doesn't. It's hard to draw that line since > >> its pretty much up to the RM and then you get heat if you draw that > >> line. IMO we should improve our release process and release a point > >> release every week shortening the vote period for that to maybe 24h. > >> That way we can get stuff out quickly and don't spend weeks on the > >> release process. > >> > >> I will call this vote here as failed and build a new RC once SOLR-5762 > is > >> in. > >> > >> simon > >> > >> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sar...@gmail.com> wrote: > >> > I volunteer to be 4.7.1 RM. > >> > > >> > I’d prefer to delay the 4.7.0 release to include all known bugfixes, > >> > though. > >> > > >> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and > handle > >> > any respins. If not, it’s your prerogative to continue with the > current RC > >> > vote; others can express their opinions by voting. I’m sure it’ll be > fine > >> > either way. > >> > > >> > Steve > >> > > >> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer < > simon.willna...@gmail.com> > >> > wrote: > >> > > >> >> Guys, I don't think we will ever get to the point where there is not > a > >> >> bug. But we have to draw a line here. If we respin I have to step > back > >> >> as the RM since I just can't spend more than 7 days on this. I think > >> >> there should be a 4.7.1 at some point where you can get your bugs > >> >> fixed as everybody else but we have to draw a line here. I think I am > >> >> going to draw it here with the 3 +1 I am having. > >> >> > >> >> simon > >> >> > >> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe > >> >> <tomasflo...@gmail.com> wrote: > >> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My > >> >>> understanding is > >> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or > >> >>> earlier? > >> >>> > >> >>> > >> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rcm...@gmail.com> > wrote: > >> >>>> > >> >>>> > >> >>>> And I think it should be under optimizations not changes in > behavior. > >> >>>> > >> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen > >> >>>> <martijn.v.gronin...@gmail.com> wrote: > >> >>>>> > >> >>>>> > >> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the > second > >> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 > >> >>>>> instead of > >> >>>>> LUCENE-4399. > >> >>>>> > >> >>>>> > >> >>> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- ----------------------------------------------------- Noble Paul
