Anshum: I really hate to ask, but do we know whether
https://issues.apache.org/jira/browse/SOLR-8496 (Facet search count numbers are falsified by older document versions) is a problem in 5.3.2? It's in 5.4.1 and we don't yet know when it was introduced. Yonik thinks this is serious enough to re-spin 5.4.1 if it's easily fixable. Don't shoot me, I'm just the messenger ;) Erick On Fri, Jan 15, 2016 at 3:44 AM, Anshum Gupta <ans...@anshumgupta.net> wrote: > Thanks Adrien and every one else. > > The vote has passed. I am traveling back to San Francisco (14 hours away) so > I will resume the release process as soon as I'm back. > > > On Thu, Jan 14, 2016 at 5:32 PM, Adrien Grand <jpou...@gmail.com> wrote: >> >> +1 SUCCESS! [1:11:11.509082] >> >> I also tried to run TestBackwardsCompatibility from the 5.4 branch on an >> index generated by this release candidate, this did not catch problems. >> >> Le mer. 13 janv. 2016 à 09:09, Adrien Grand <jpou...@gmail.com> a écrit : >>> >>> Le mer. 13 janv. 2016 à 07:19, Ryan Ernst <r...@iernst.net> a écrit : >>>> >>>> While this isn't something we have tests for in >>>> TestBackwardsCompatibility (that only tests every previous version against >>>> the current version), we do have tests in TestVersion for parsing versions >>>> that do not have constants (see testForwardsCompatibility). Version >>>> constants are only shortcuts to Version objects with known values, not what >>>> are passed around. >>> >>> >>> Thanks Ryan. So the version part should be fine at least. >>> >>>>> On Wed, Jan 13, 2016 at 2:31 AM, Yonik Seeley <ysee...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Seems like this versioning limitation should be fixed - we should >>>>>> always be free to create bugfix releases for past releases. >>> >>> >>> While I agree it should not prevent us from releasing as it is something >>> that we would need to do anyway for instance if we discover a serious >>> corruption bug, it still puts us in an lesser known territory that means >>> that we need to be more careful when testing the release. >>> >>> Most of the work has already been done so I don't think we should cancel >>> this release, we just need to test more carefully, but this is something >>> that would refrain me from proposing to do bugfix releases of previous minor >>> releases again in the future, unless there is a major bug that needs to be >>> adressed. > > > > > -- > Anshum Gupta --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org