lucene-dev mailing list archives

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


Uwe Schindler updated LUCENE-5850:

    Attachment: LUCENE-5850.patch


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 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 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

> 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