search

apache / lucene

Apache Lucene open-source search software
https://lucene.apache.org/
Apache License 2.0
2.6k stars 1.01k forks source link

Constants#LUCENE_MAIN_VERSION can have broken values [LUCENE-5850] #6912

Closed asfimport closed 10 years ago

asfimport commented 10 years ago

Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should not contain minor versions. Well this is at least what I thought and to my knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we broke this such that the version from SegmentsInfo can not be parsed with Version#parseLeniently. IMO we should really add an assertion that this constant doesn't throw an error and / or make the smoketester catch this. to me this is actually a index BWC break. Note that 4.8.1 doesn't have this problem...

Migrated from LUCENE-5850 by Simon Willnauer (@s1monw), resolved Aug 16 2014 Attachments: LUCENE-5850_bomb.patch, LUCENE-5850_hashcode.patch, LUCENE-5850_smoketester.patch, LUCENE-5850.patch (versions: 9), LUCENE-5860_hashcode.patch Linked issues:

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Sorry Robert it is. In 4.9.1 it would write LUCENE_MAIN_VERSION with "4.9". My earlier fix enforces this. If you would use LUCENE_MAIN_VERSION="4.9.1" it would fail to run tests already.

The bugs were in older versions that has an incorrect value. The bugs are indeed older 4.5.1 and 4.3.1 versions. See Simon's original issue description.

The assumption you have is that it might happen that LUCENE_MAIN_VERSION is "4.9.1", which it can never be, unless you disable TestConstants, added in 4.7.

asfimport commented 10 years ago

Robert Muir (@rmuir) (migrated from JIRA)

I think this issue should definitely block any 4.9.1, sorry.

This versioning stuff is a mess and I would vote -1 to any release without it fixed, otherwise the possibility of bugs and mistakes is just too high.

asfimport commented 10 years ago

Robert Muir (@rmuir) (migrated from JIRA)

The assumption you have is that it might happen that LUCENE_MAIN_VERSION is "4.9.1", which it can never be

But it should be if 4.9.1 is going to have any significant changes. Otherwise if we make a mistake, we cant correct it, as we will be unable to differentiate between 4.9 and 4.9.1 indexes.

This is a really big problem.

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

But it should be if 4.9.1 is going to have any significant changes. Otherwise if we make a mistake, we cant correct it, as we will be unable to differentiate between 4.9 and 4.9.1 indexes.

I agree, this is why we decided to do it differently. But this would not prevent a bugfix release of current 4.9 branch. It would just use the old semantics to only write the major x.y version to the index files.

I 100% agree, we should fix this in 4.10!

My question on this issue was just: Should I commit the current work and we then open a new issue to merge MAIN_VERSION and Version.java, as Ryan suggests? This issue has many cleanups and better tests, so its easier as base for the big "Version" refactoring by Ryan.

asfimport commented 10 years ago

Robert Muir (@rmuir) (migrated from JIRA)

But this would not prevent a bugfix release of current 4.9 branch.

Nope, it wouldnt. it would just prevent index backwards compatibility support for such a release. If we want to relax our index back compat requirement such that we don't need to be able to read such 4.9/4.9.1 in the future, then the versioning can be a mess.

Otherwise it needs to be correct.

asfimport commented 10 years ago

Ryan Ernst (@rjernst) (migrated from JIRA)

This patch consolidates LUCENE_MAIN_VERSION and associated parsing/comparison code into Version.java. Specifically, it:

I've probably forgot some things. All tests pass.

asfimport commented 10 years ago

Ryan Ernst (@rjernst) (migrated from JIRA)

I would like to commit this Friday morning PDT if there are no objections.

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

You patch no longer contains a check that the actual Version.LATEST is the one thats also in common-build.xml? I added that for extra safety.

asfimport commented 10 years ago

Ryan Ernst (@rjernst) (migrated from JIRA)

Sorry about that Uwe. This new patch adds back a test to check the build version against Version.LATEST.

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Thanks!

+1 to commit!

One small thing: can we make Version class final?

asfimport commented 10 years ago

Ryan Ernst (@rjernst) (migrated from JIRA)

Ok, one more patch with Version made final, version.luceneMatchVersion set to version.base, and the ant version now including the bugfix version as the comment described.

asfimport commented 10 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1618263 from @rjernst in branch 'dev/trunk' https://svn.apache.org/r1618263

LUCENE-5850: Made Version handling more robust and extensible

asfimport commented 10 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1618282 from @uschindler in branch 'dev/trunk' https://svn.apache.org/r1618282

LUCENE-5850: Remove useless checks and properties

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Hi Ryan, I added another commit removing some useless (now duplicate) checks in common-build.xml (we discussed yesterday on Hangouts...)

asfimport commented 10 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1618309 from @rjernst in branch 'dev/branches/branch_4x' https://svn.apache.org/r1618309

LUCENE-5850: Made Version handling more robust and extensible

asfimport commented 10 years ago

Simon Willnauer (@s1monw) (migrated from JIRA)

@rjernst I looked at the commit and I don't see a hashcode implementation in Version.java but it has an equals one. I think it's bad that none of the tests catches that though I think we should add on. I can get to it tomorrow or so but please feel free to beat me.

asfimport commented 10 years ago

Simon Willnauer (@s1monw) (migrated from JIRA)

here is a simple patch and a test - I am actually disappointed that uwe didn't catch this :)

asfimport commented 10 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I am actually disappointed that uwe didn't catch this

Krrrrrrr! :-(

asfimport commented 10 years ago

Ryan Ernst (@rjernst) (migrated from JIRA)

Looks good, thanks for the fix. Just one minor thing:

assertEquals(Version.parseLeniently(v), v1.hashCode());

I think this needs a call to hashCode() for the parsed value?

asfimport commented 10 years ago

Simon Willnauer (@s1monw) (migrated from JIRA)

ahh good catch I will fix

asfimport commented 10 years ago

Simon Willnauer (@s1monw) (migrated from JIRA)

fixed test bug

asfimport commented 10 years ago

Simon Willnauer (@s1monw) (migrated from JIRA)

removed @Repeat - I guess it's ready

asfimport commented 10 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1618621 from @s1monw in branch 'dev/trunk' https://svn.apache.org/r1618621

LUCENE-5850: Add missing hashCode implementation to Version.java

asfimport commented 10 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1618639 from @s1monw in branch 'dev/branches/branch_4x' https://svn.apache.org/r1618639

LUCENE-5850: Add missing hashCode implementation to Version.java