[
https://issues.apache.org/jira/browse/LUCENE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079173#comment-14079173
]
Uwe Schindler edited comment on LUCENE-5850 at 7/30/14 11:02 AM:
-----------------------------------------------------------------
Hi,
Please note: The problem mentioned in the original issue description
("Constants#LUCENE_MAIN_VERSION can have broken values") was not a problem
anymore because of LUCENE-5537 (since 4.8). The original documentation said
that LUCENE_MAIN_VERSION should only be in format {{x.y}} but because of the
missing test introduced in LUCENE-5537, we had some outlyers in the past. 4.8.1
was therefore correct with LUCENE_MAIN_VERSION="4.8".
In this issue we now decided that we should record the full (numeric) version
number (without appendinxes) in index segments. Smoke tester already checks
this now, but the tests were not confirming (still enforcing x.y format from
LUCENE-5537).
I worked on a patch that cleans up the version handling in
Constants.java/Version.java and common-build.xml. It also contains improved
tests:
- LUCENE_MAIN_VERSION must be identical to common-builds "version.base"
property. This is checked in the test. Previously, this was just a broken
startsWith check on the full version.
- I cleaned up all broken constants in common-build. We now solely have
"version.base" and "version.suffix". "version" is constructed from both. The RM
can enforce a release version without appendix by passing {{-Dversion=...}},
but common-build.xml validates the value passed in conformance with the fixed
version.base constant, so you cannot release 4.10 with wrong MAIN_VERSION that
would affect constants written to segments.
- _To support ALPHA/BETA versions (like Robert introduced in 4.0-ALPHA), you
can set a boolean to true in Constants.java. By that it automatically appends
".0.1" at the end of the MAIN_VERSION. In my opinion, we should rethink this,
the idea was cool, but adds stupid complexity to the simple checks and changes
I did. Maybe we should release ALPHA/BETA versions in a different way with
different versioning). For now I implemented it like Robert did it._ Maybe
Roert can review, I am not really happy.
- I changed Version.parseLeniently() to allow minor bugfix versions given (so
users can write "4.9.1" into their config files, but its parsed to LUCENE_4_9),
which would be the corresponding match version constant. This is also checked
in the test. This also solves the 1.3.1 hotfix release of Elasticsearch, which
also misused parseLeniently in an non-approp way (like Shai did):
http://github.com/elasticsearch/elasticsearch/issues/issue/7055
was (Author: thetaphi):
Hi,
Please note: The problem mentioned in the original issue description
("Constants#LUCENE_MAIN_VERSION can have broken values") was not a problem
anymore because of LUCENE-5537 (since 4.8). The original documentation said
that LUCENE_MAIN_VERSION should only be in format {{x.y}} but because of the
missing test introduced in LUCENE-5537, we had some outlyers in the past. 4.8.1
was therefore correct with LUCENE_MAIN_VERSION="4.8".
In this issue we now decided that we should record the full (numeric) version
number (without appendinxes) in index segments. Smoke tester already checks
this now, but the tests were not confirming (still enforcing x.y format from
LUCENE-5537).
I worked on a patch that cleans up the version handling in
Constants.java/Version.java and common-build.xml. It also contains improved
tests:
- LUCENE_MAIN_VERSION must be identical to common-builds "version.base"
property. This is checked in the test. Previously, this was just a broken
startsWith check on the full version.
- I cleaned up all broken constants in common-build. We now solely have
"version.base" and "version.suffix". "version" is constructed from both. The RM
can enforce a release version without appendix by passing {{-Dversion=...}},
but common-build.xml validates the value passed in conformance with the fixed
version.base constant, so you cannot release 4.10 with wrong MAIN_VERSION that
would affect constants written to segments.
- _To support ALPHA/BETA versions (like Robert introduced in 4.0-ALPHA), you
can set a boolean to true in Constants.java. By that it automatically appends
".0.1" at the end of the MAIN_VERSION. In my opinion, we should rething this,
the idea was cool, but adds stupid complexity to the simple checks and changes
I did. Maybe we should release ALPHA/BETA versions in a different way with
different versioning). For now I implemented it like Robert did it._ Maybe
Roert can review, I am not really happy.
- I changed Version.parseLeniently() to allow minor bugfix versions given (so
users can write "4.9.1" into their config files, but its parsed to LUCENE_4_9),
which would be the corresponding match version constant. This is also checked
in the test. This also solves the 1.3.1 hotfix release of Elasticsearch, which
also misused parseLeniently in an non-approp way (like Shai did):
http://github.com/elasticsearch/elasticsearch/issues/issue/7055
> 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: [email protected]
For additional commands, e-mail: [email protected]
