[
https://issues.apache.org/jira/browse/LUCENE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079212#comment-14079212
]
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 Version.java 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. Version.java 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: https://issues.apache.org/jira/browse/LUCENE-5850
> 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
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
