Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.10.1, 5.0, 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Thank you mike for the smoketester addition. It failed because 4.10.1 was not verifying backwards compatibility against 4.10

      However, when i added the indexes (svn copied from branch-4x), the test fails.

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment - - edited

          I extracted the 410.cfs.zip file and ran checkindex on it (of course i used the newer version, because I wanted to see the real version):

          C:\Users\Uwe Schindler\Desktop>java -cp lucene-core-4.11.0-SNAPSHOT.jar org.apache.lucene.index.CheckIndex index
          
          NOTE: testing will be more thorough if you run java with '-ea:org.apache.lucene...', so assertions are enabled
          
          Opening index @ index
          
          Segments file=segments_3 numSegments=5 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faab format=
            1 of 5: name=_0 docCount=10
              version=4.11.0
              id=90e2ef40edf76628be731bdca9c8faa4
              codec=Lucene410
              compound=true
              numFiles=4
              size (MB)=0.008
              diagnostics = {timestamp=1409886841199, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav
          a.version=1.7.0_60, java.vendor=Oracle Corporation}
              has deletions [delGen=1]
              test: open reader.........OK
              test: check integrity.....OK
              test: check live docs.....OK [1 deleted docs]
              test: fields..............OK [25 fields]
              test: field norms.........OK [7 fields]
              test: terms, freq, prox...OK [64 terms; 360 terms/docs pairs; 333 tokens]
              test (ignoring deletes): terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens]
              test: stored fields.......OK [63 total field count; avg 7 fields per doc]
              test: term vectors........OK [54 total vector count; avg 6 term/freq vector fields per doc]
              test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET]
          
            2 of 5: name=_1 docCount=10
              version=4.11.0
              id=90e2ef40edf76628be731bdca9c8faa5
              codec=Lucene410
              compound=true
              numFiles=3
              size (MB)=0.008
              diagnostics = {timestamp=1409886841241, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav
          a.version=1.7.0_60, java.vendor=Oracle Corporation}
              no deletions
              test: open reader.........OK
              test: check integrity.....OK
              test: check live docs.....OK
              test: fields..............OK [25 fields]
              test: field norms.........OK [7 fields]
              test: terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens]
              test: stored fields.......OK [70 total field count; avg 7 fields per doc]
              test: term vectors........OK [60 total vector count; avg 6 term/freq vector fields per doc]
              test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET]
          
            3 of 5: name=_2 docCount=10
              version=4.11.0
              id=90e2ef40edf76628be731bdca9c8faa6
              codec=Lucene410
              compound=true
              numFiles=3
              size (MB)=0.008
              diagnostics = {timestamp=1409886841273, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav
          a.version=1.7.0_60, java.vendor=Oracle Corporation}
              no deletions
              test: open reader.........OK
              test: check integrity.....OK
              test: check live docs.....OK
              test: fields..............OK [25 fields]
              test: field norms.........OK [7 fields]
              test: terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens]
              test: stored fields.......OK [70 total field count; avg 7 fields per doc]
              test: term vectors........OK [60 total vector count; avg 6 term/freq vector fields per doc]
              test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET]
          
            4 of 5: name=_3 docCount=5
              version=4.11.0
              id=90e2ef40edf76628be731bdca9c8faa7
              codec=Lucene410
              compound=true
              numFiles=3
              size (MB)=0.007
              diagnostics = {timestamp=1409886841292, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav
          a.version=1.7.0_60, java.vendor=Oracle Corporation}
              no deletions
              test: open reader.........OK
              test: check integrity.....OK
              test: check live docs.....OK
              test: fields..............OK [25 fields]
              test: field norms.........OK [7 fields]
              test: terms, freq, prox...OK [52 terms; 200 terms/docs pairs; 185 tokens]
              test: stored fields.......OK [35 total field count; avg 7 fields per doc]
              test: term vectors........OK [30 total vector count; avg 6 term/freq vector fields per doc]
              test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET]
          
            5 of 5: name=_4 docCount=1
              version=4.11.0
              id=90e2ef40edf76628be731bdca9c8faa9
              codec=Lucene410
              compound=true
              numFiles=3
              size (MB)=0.001
              diagnostics = {timestamp=1409886841318, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav
          a.version=1.7.0_60, java.vendor=Oracle Corporation}
              no deletions
              test: open reader.........OK
              test: check integrity.....OK
              test: check live docs.....OK
              test: fields..............OK [2 fields]
              test: field norms.........OK [1 fields]
              test: terms, freq, prox...OK [1 terms; 1 terms/docs pairs; 0 tokens]
              test: stored fields.......OK [2 total field count; avg 2 fields per doc]
              test: term vectors........OK [0 total vector count; avg 0 term/freq vector fields per doc]
              test: docvalues...........OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET]
          
          No problems were detected with this index.
          

          So this index was created with 4.11.0, no idea how this happened! So the RM Ryan seem to created a wrong index!

          Show
          Uwe Schindler added a comment - - edited I extracted the 410.cfs.zip file and ran checkindex on it (of course i used the newer version, because I wanted to see the real version): C:\Users\Uwe Schindler\Desktop>java -cp lucene-core-4.11.0-SNAPSHOT.jar org.apache.lucene.index.CheckIndex index NOTE: testing will be more thorough if you run java with '-ea:org.apache.lucene...', so assertions are enabled Opening index @ index Segments file=segments_3 numSegments=5 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faab format= 1 of 5: name=_0 docCount=10 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faa4 codec=Lucene410 compound=true numFiles=4 size (MB)=0.008 diagnostics = {timestamp=1409886841199, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav a.version=1.7.0_60, java.vendor=Oracle Corporation} has deletions [delGen=1] test: open reader.........OK test: check integrity.....OK test: check live docs.....OK [1 deleted docs] test: fields..............OK [25 fields] test: field norms.........OK [7 fields] test: terms, freq, prox...OK [64 terms; 360 terms/docs pairs; 333 tokens] test (ignoring deletes): terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens] test: stored fields.......OK [63 total field count; avg 7 fields per doc] test: term vectors........OK [54 total vector count; avg 6 term/freq vector fields per doc] test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET] 2 of 5: name=_1 docCount=10 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faa5 codec=Lucene410 compound=true numFiles=3 size (MB)=0.008 diagnostics = {timestamp=1409886841241, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav a.version=1.7.0_60, java.vendor=Oracle Corporation} no deletions test: open reader.........OK test: check integrity.....OK test: check live docs.....OK test: fields..............OK [25 fields] test: field norms.........OK [7 fields] test: terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens] test: stored fields.......OK [70 total field count; avg 7 fields per doc] test: term vectors........OK [60 total vector count; avg 6 term/freq vector fields per doc] test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET] 3 of 5: name=_2 docCount=10 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faa6 codec=Lucene410 compound=true numFiles=3 size (MB)=0.008 diagnostics = {timestamp=1409886841273, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav a.version=1.7.0_60, java.vendor=Oracle Corporation} no deletions test: open reader.........OK test: check integrity.....OK test: check live docs.....OK test: fields..............OK [25 fields] test: field norms.........OK [7 fields] test: terms, freq, prox...OK [67 terms; 400 terms/docs pairs; 370 tokens] test: stored fields.......OK [70 total field count; avg 7 fields per doc] test: term vectors........OK [60 total vector count; avg 6 term/freq vector fields per doc] test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET] 4 of 5: name=_3 docCount=5 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faa7 codec=Lucene410 compound=true numFiles=3 size (MB)=0.007 diagnostics = {timestamp=1409886841292, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav a.version=1.7.0_60, java.vendor=Oracle Corporation} no deletions test: open reader.........OK test: check integrity.....OK test: check live docs.....OK test: fields..............OK [25 fields] test: field norms.........OK [7 fields] test: terms, freq, prox...OK [52 terms; 200 terms/docs pairs; 185 tokens] test: stored fields.......OK [35 total field count; avg 7 fields per doc] test: term vectors........OK [30 total vector count; avg 6 term/freq vector fields per doc] test: docvalues...........OK [15 docvalues fields; 4 BINARY; 7 NUMERIC; 2 SORTED; 1 SORTED_NUMERIC; 1 SORTED_SET] 5 of 5: name=_4 docCount=1 version=4.11.0 id=90e2ef40edf76628be731bdca9c8faa9 codec=Lucene410 compound=true numFiles=3 size (MB)=0.001 diagnostics = {timestamp=1409886841318, os=Mac OS X, os.version=10.9.4, source=flush, lucene.version=4.11.0, os.arch=x86_64, jav a.version=1.7.0_60, java.vendor=Oracle Corporation} no deletions test: open reader.........OK test: check integrity.....OK test: check live docs.....OK test: fields..............OK [2 fields] test: field norms.........OK [1 fields] test: terms, freq, prox...OK [1 terms; 1 terms/docs pairs; 0 tokens] test: stored fields.......OK [2 total field count; avg 2 fields per doc] test: term vectors........OK [0 total vector count; avg 0 term/freq vector fields per doc] test: docvalues...........OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET] No problems were detected with this index. So this index was created with 4.11.0, no idea how this happened! So the RM Ryan seem to created a wrong index!
          Hide
          Uwe Schindler added a comment - - edited

          This is why I argued yesterday, that we should at least do some consistency check in TestBackwards, so the index version is sanity checked (if available).

          Maybe we should really add this check:

          • if the backwards index has a version set, check it (with the offenders taken care)
          • if not (older ones) dont do anything
          Show
          Uwe Schindler added a comment - - edited This is why I argued yesterday, that we should at least do some consistency check in TestBackwards, so the index version is sanity checked (if available). Maybe we should really add this check: if the backwards index has a version set, check it (with the offenders taken care) if not (older ones) dont do anything
          Hide
          Uwe Schindler added a comment -

          I suspect there are more of those...

          Show
          Uwe Schindler added a comment - I suspect there are more of those...
          Hide
          Robert Muir added a comment -

          Lets fix the test to have some checks. otherwise I am forced to inspect each one manually, at least the ones i did not generate yesterday.

          Show
          Robert Muir added a comment - Lets fix the test to have some checks. otherwise I am forced to inspect each one manually, at least the ones i did not generate yesterday.
          Hide
          Robert Muir added a comment -

          And yeah, actually we cant much do any automatic verification because we dont know, for example, if 4.5 was really made with 4.5 or maybe 4.5.1 (if they wrote the same version string). We should add the checks moving forwards, but i fear there is no way out of manual verification for now.

          Show
          Robert Muir added a comment - And yeah, actually we cant much do any automatic verification because we dont know, for example, if 4.5 was really made with 4.5 or maybe 4.5.1 (if they wrote the same version string). We should add the checks moving forwards, but i fear there is no way out of manual verification for now.
          Hide
          Uwe Schindler added a comment -

          I think we should a least create a real 4.10 index! Otherwise Robert has another mad day!

          Show
          Uwe Schindler added a comment - I think we should a least create a real 4.10 index! Otherwise Robert has another mad day!
          Hide
          Uwe Schindler added a comment -

          Ryan Ernst: Would it be possible to recreate the 4.10 backwards compatibility index (by downloading the tag or the source.tgz)? The current 4.10 backwards index in trunk and 4.x has version "4.11" recorded in segments.

          Show
          Uwe Schindler added a comment - Ryan Ernst : Would it be possible to recreate the 4.10 backwards compatibility index (by downloading the tag or the source.tgz)? The current 4.10 backwards index in trunk and 4.x has version "4.11" recorded in segments.
          Hide
          Ryan Ernst added a comment -

          Yes, I can do this. I think the problem was my tool had already updated Version.LATEST, which is what is written. Now that we are doing a backcompat index per version, instead of only when the codec changes, I think it will become easier. But I will first correct this index before fixing bumpVersion.py.

          Show
          Ryan Ernst added a comment - Yes, I can do this. I think the problem was my tool had already updated Version.LATEST, which is what is written. Now that we are doing a backcompat index per version, instead of only when the codec changes, I think it will become easier. But I will first correct this index before fixing bumpVersion.py.
          Hide
          ASF subversion and git services added a comment -

          Commit 1624385 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624385 ]

          LUCENE-5939: Fix 410 backcompat index to be built from tag of 4.10.0 release

          Show
          ASF subversion and git services added a comment - Commit 1624385 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624385 ] LUCENE-5939 : Fix 410 backcompat index to be built from tag of 4.10.0 release
          Hide
          Ryan Ernst added a comment -

          I started to try and regenerate all the indexes for previous versions which Robert did not handle in LUCENE-5863. However, I already found something odd with 4.9.0. Running check index (from 4.10) on the regen index I get:

          Segments file=segments_3 numSegments=5 version=4.9.0 format=
            1 of 5: name=_0 docCount=10
              version=4.9.0
              codec=Lucene49
              compound=true
              numFiles=4
              size (MB)=0.008
              diagnostics = {timestamp=1410470919104, os=Mac OS X, os.version=10.9.4, lucene.version=4.9-SNAPSHOT, source=flush, os.arch=x86_64, java.version=1.7.0_60, java.vendor=Oracle Corporation}
          ....
          

          Notice under diagnostics, lucene.version=4.9-SNAPSHOT. I checked this tag out:
          http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_9_0/

          So then I checked lucene/common-build.xml, and version is indeed set to 4.9-SNAPSHOT. I then downloaded the official source release, and there too the version was 4.9-SNAPSHOT.

          But, this is only the "display version", so I don't think it matters (as far as backcompat is concerned)? I am going to consider this ok and continue with the generating the other indexes.

          Show
          Ryan Ernst added a comment - I started to try and regenerate all the indexes for previous versions which Robert did not handle in LUCENE-5863 . However, I already found something odd with 4.9.0. Running check index (from 4.10) on the regen index I get: Segments file=segments_3 numSegments=5 version=4.9.0 format= 1 of 5: name=_0 docCount=10 version=4.9.0 codec=Lucene49 compound=true numFiles=4 size (MB)=0.008 diagnostics = {timestamp=1410470919104, os=Mac OS X, os.version=10.9.4, lucene.version=4.9-SNAPSHOT, source=flush, os.arch=x86_64, java.version=1.7.0_60, java.vendor=Oracle Corporation} .... Notice under diagnostics, lucene.version=4.9-SNAPSHOT . I checked this tag out: http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_9_0/ So then I checked lucene/common-build.xml, and version is indeed set to 4.9-SNAPSHOT. I then downloaded the official source release, and there too the version was 4.9-SNAPSHOT. But, this is only the "display version", so I don't think it matters (as far as backcompat is concerned)? I am going to consider this ok and continue with the generating the other indexes.
          Hide
          Uwe Schindler added a comment - - edited

          So then I checked lucene/common-build.xml, and version is indeed set to 4.9-SNAPSHOT. I then downloaded the official source release, and there too the version was 4.9-SNAPSHOT.

          This is correct. When we build the release artifacts, the version is overwritten with -Dversion=xxxx. If you build lucene from source you always have SNAPSHOT versions. This is done to differentiate then from "official builds". "lucene.version" is a metadata field that is initialized with the "human-readable version", which now disappeared in 4.10, because we no longer read the JAR manifest.

          Show
          Uwe Schindler added a comment - - edited So then I checked lucene/common-build.xml, and version is indeed set to 4.9-SNAPSHOT. I then downloaded the official source release, and there too the version was 4.9-SNAPSHOT. This is correct. When we build the release artifacts, the version is overwritten with -Dversion=xxxx. If you build lucene from source you always have SNAPSHOT versions. This is done to differentiate then from "official builds". "lucene.version" is a metadata field that is initialized with the "human-readable version", which now disappeared in 4.10, because we no longer read the JAR manifest.
          Hide
          Uwe Schindler added a comment -

          By the way, this "displayversion" string is the reason why I was not so happy that you removed it in 4.10. I renamed the constant to LUCENE_DISPLAY_VERSION in my patch. You said, the information is useless (like svn rev number or user that build or full version). It is in fact not. From that you can determine, if an index was built using the "original lucene jars" or some (maybe modified) private compiled versions. So I would really like to have that LUCENE_DISPLAY_VERSION back (currently the constant LUCENE_VERSION that contained this is deprecated). I would really like to write this version (e.g. as display or full version string to the commit metadata). I had one customers where i found out that they patched their lucene, causing corrumption. Based on the CheckIndex output this was easy to detect. The display/full version including rev no and user and appendix is in the JAR Manifest (which is good), but no longer in index metadata!

          Show
          Uwe Schindler added a comment - By the way, this "displayversion" string is the reason why I was not so happy that you removed it in 4.10. I renamed the constant to LUCENE_DISPLAY_VERSION in my patch. You said, the information is useless (like svn rev number or user that build or full version). It is in fact not. From that you can determine, if an index was built using the "original lucene jars" or some (maybe modified) private compiled versions. So I would really like to have that LUCENE_DISPLAY_VERSION back (currently the constant LUCENE_VERSION that contained this is deprecated). I would really like to write this version (e.g. as display or full version string to the commit metadata). I had one customers where i found out that they patched their lucene, causing corrumption. Based on the CheckIndex output this was easy to detect. The display/full version including rev no and user and appendix is in the JAR Manifest (which is good), but no longer in index metadata!
          Hide
          Uwe Schindler added a comment -

          P.S.: The reason why you see "4.9-SNAPSHOT" is caused by the fact that while running tests, you have no JAR file, so the constant was initialized as a fake (see former code of Constants.java). If you would create the index with a real JAR file you would see the same string like in JAR's MANIFEST.MF under "Implementation-Version". Maybe we should name the metadata key like that!

          Show
          Uwe Schindler added a comment - P.S.: The reason why you see "4.9-SNAPSHOT" is caused by the fact that while running tests, you have no JAR file, so the constant was initialized as a fake (see former code of Constants.java). If you would create the index with a real JAR file you would see the same string like in JAR's MANIFEST.MF under "Implementation-Version". Maybe we should name the metadata key like that!
          Hide
          ASF subversion and git services added a comment -

          Commit 1624418 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624418 ]

          LUCENE-5939: Regenerate 4.9.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624418 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624418 ] LUCENE-5939 : Regenerate 4.9.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624448 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624448 ]

          LUCENE-5939: Regenerate 4.6.1 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624448 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624448 ] LUCENE-5939 : Regenerate 4.6.1 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624461 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624461 ]

          LUCENE-5939: Regenerate 4.5.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624461 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624461 ] LUCENE-5939 : Regenerate 4.5.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624463 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624463 ]

          LUCENE-5939: Regenerate 4.2.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624463 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624463 ] LUCENE-5939 : Regenerate 4.2.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624466 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624466 ]

          LUCENE-5939: Regenerate 4.1.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624466 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624466 ] LUCENE-5939 : Regenerate 4.1.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624652 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624652 ]

          LUCENE-5939: Regenerate 3.4.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624652 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624652 ] LUCENE-5939 : Regenerate 3.4.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624656 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624656 ]

          LUCENE-5939: Regenerate 3.2.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624656 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624656 ] LUCENE-5939 : Regenerate 3.2.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624658 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624658 ]

          LUCENE-5939: Regenerate 3.1.0 backcompat index

          Show
          ASF subversion and git services added a comment - Commit 1624658 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624658 ] LUCENE-5939 : Regenerate 3.1.0 backcompat index
          Hide
          ASF subversion and git services added a comment -

          Commit 1624659 from Ryan Ernst in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1624659 ]

          LUCENE-5939: Regenerate old backcompat indexes to ensure they were built with the exact release

          Show
          ASF subversion and git services added a comment - Commit 1624659 from Ryan Ernst in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1624659 ] LUCENE-5939 : Regenerate old backcompat indexes to ensure they were built with the exact release
          Hide
          ASF subversion and git services added a comment -

          Commit 1624660 from Ryan Ernst in branch 'dev/trunk'
          [ https://svn.apache.org/r1624660 ]

          LUCENE-5939: Regenerate old backcompat indexes to ensure they were built with the exact release

          Show
          ASF subversion and git services added a comment - Commit 1624660 from Ryan Ernst in branch 'dev/trunk' [ https://svn.apache.org/r1624660 ] LUCENE-5939 : Regenerate old backcompat indexes to ensure they were built with the exact release
          Hide
          ASF subversion and git services added a comment -

          Commit 1624661 from Ryan Ernst in branch 'dev/trunk'
          [ https://svn.apache.org/r1624661 ]

          LUCENE-5939: Add changes entry

          Show
          ASF subversion and git services added a comment - Commit 1624661 from Ryan Ernst in branch 'dev/trunk' [ https://svn.apache.org/r1624661 ] LUCENE-5939 : Add changes entry
          Hide
          ASF subversion and git services added a comment -

          Commit 1624662 from Ryan Ernst in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1624662 ]

          LUCENE-5939: Add changes entry (merged 1624661)

          Show
          ASF subversion and git services added a comment - Commit 1624662 from Ryan Ernst in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1624662 ] LUCENE-5939 : Add changes entry (merged 1624661)
          Hide
          ASF subversion and git services added a comment -

          Commit 1624663 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624663 ]

          LUCENE-5939: Add changes entry (merged 1624662)

          Show
          ASF subversion and git services added a comment - Commit 1624663 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624663 ] LUCENE-5939 : Add changes entry (merged 1624662)
          Hide
          ASF subversion and git services added a comment -

          Commit 1624668 from Ryan Ernst in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1624668 ]

          LUCENE-5939: Fix backcompat test to not look for numerics in <= 3.2 (instead of <= 3.1)

          Show
          ASF subversion and git services added a comment - Commit 1624668 from Ryan Ernst in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1624668 ] LUCENE-5939 : Fix backcompat test to not look for numerics in <= 3.2 (instead of <= 3.1)
          Hide
          ASF subversion and git services added a comment -

          Commit 1624669 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1624669 ]

          LUCENE-5939: Fix backcompat test to not look for numerics in <= 3.2 (instead of <= 3.1)

          Show
          ASF subversion and git services added a comment - Commit 1624669 from Ryan Ernst in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1624669 ] LUCENE-5939 : Fix backcompat test to not look for numerics in <= 3.2 (instead of <= 3.1)
          Hide
          Michael McCandless added a comment -

          Bulk close for Lucene/Solr 4.10.1 release

          Show
          Michael McCandless added a comment - Bulk close for Lucene/Solr 4.10.1 release

            People

            • Assignee:
              Ryan Ernst
              Reporter:
              Robert Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development