[
https://issues.apache.org/jira/browse/LUCENE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134667#comment-14134667
]
Uwe Schindler commented on LUCENE-5952:
---------------------------------------
bq. Wait, it was lenient before. It was just a string. Unrelated to
version.java in any way.
Version.java was not lenient at all. In the past Version.java was very strict
(only allowed the constants). For parsing index version numbers we used another
comparator, which was lenient and accepted any version number to compare (like
the Maven version comparator). Now its both in one class and therefore we have
to relax Version.java more, to be future proof.
Before it was enum, now its a simple class with some additional bounds on major
version. We just have to remove the major version constraint.
_In my opinion, we should not save index version as string at all and instead
save the "encoded value" and an (v)int._
> Make Version.java lenient again?
> --------------------------------
>
> Key: LUCENE-5952
> URL: https://issues.apache.org/jira/browse/LUCENE-5952
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5952.patch
>
>
> As discussed on the dev list, it's spooky how Version.java tries to fully
> parse the incoming version string ... and then throw exceptions that lack
> details about what invalid value it received, which file contained the
> invalid value, etc.
> It also seems too low level to be checking versions (e.g. is not future proof
> for when 4.10 is passed a 5.x index by accident), and seems redundant with
> the codec headers we already have for checking versions?
> Should we just go back to lenient parsing?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
