lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values
Date Wed, 30 Jul 2014 11:53:39 GMT


Uwe Schindler commented on LUCENE-5850:

bq. But thats not what we did. Alpha, Beta, and Final all had 3 distinct version numbers.

I know, this was just a quick hack to support maybe the same in Lucene 5.0. The idea of the
".0.1" was just to prevent people from using indexes created in beta versions with the released
version. So the ".0.1" was perfectly fine to enforce this. But it did not help once 4.1 was
out. ndexes created with 4.0.ALPHA did not fail if read with 4.1 (only with 4.0)! In my opinion,
we should mark BETA indexes in a different way with LUCENE 5.0. This is why I said this should
be reviewed. We should have a marker "ALPHA/BETA" in the index file and fail to read it, This
is unrelated to this patch - I would be happy to remove the whole ALPHA/BETA checks. To emulate
your behaviour, we could remove

bq. Why not just merge with to eliminate yet-another-version? We still have too
many, and this is still asking for bugs, just different types of bugs. We can just add the
previous release constants to the enum.

I disagree. was and is never intended to be used to specifiy real Lucene versions.
Version is there to enable backwards compatibility hacks when passing in as constant to enable
backwards compatibility hacks. We also remove older constants!

Elasticsearch and Shai Erea were simply doing the completely wrong thing. Version constants
are there to enable backwards layers. parseLeniently was there to allow users to specify.
Why does Elasticsearch not simply print the fucking String from the segment metadata? Sorry,
what is described in the issue and the fix in ES 1.3.1 is bullshit^3!

The parseLeniently hack added here was just for convenience. I should remove it completely
- it was just here to help Elasticsearch! Sorry - will go away in next patch.

*In Lucene we just have 2 versions: Constants for reporting metadata and save it in index
files. The Version enum is for enabling backwards hacks in Solr's and ES's config files. The
parser was added to help Lucene users to pass those constants in config files.*

The big question to [~simonw]: Why does ES not report the real version number as _string_
in the root REST API?

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -----------------------------------------------------
>                 Key: LUCENE-5850
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: general/build
>    Affects Versions: 4.3.1, 4.5.1
>            Reporter: Simon Willnauer
>             Fix For: 5.0, 4.10
>         Attachments: LUCENE-5850.patch, LUCENE-5850.patch, LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
> 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...

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message