[
https://issues.apache.org/jira/browse/LUCENE-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160283#comment-14160283
]
Jack Krupansky commented on LUCENE-5992:
----------------------------------------
What about "versions" of an index during the development process, like each
time a change to the index format is committed? Such as the alpha and beta
stages in 4.0?
I'd be happier with four version ints: major, minor, patch, "change".
Although, in theory, we shouldn't be changing the index format in either minor
or patch releases, but bug fixes for indexing can be valid changes as well.
Now, the question is whether "change" should reset to zero each time we branch,
or should really just be an ever-increasing "index format version number." The
latter may make sense, but either is fine. The latter also makes sense from the
perspective of the potential of successive releases which don't introduce index
incompatibilities. I lean towards the latter, but still makes sense to
defensively record which release wrote an index.
> Version should not be encoded as a String in the index
> ------------------------------------------------------
>
> Key: LUCENE-5992
> URL: https://issues.apache.org/jira/browse/LUCENE-5992
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5992.patch
>
>
> The version is really "just" 3 (maybe 4) ints under-the-hood, but today we
> write it as a String which then requires spooky string tokenization/parsing
> when we open the index. I think it should be encoded directly as ints.
> In LUCENE-5952 I had tried to make this change, but it was controversial, and
> got booted.
> Then in LUCENE-5969, I tried again, but that issue has morphed (nicely!) into
> fixing all sorts of things *except* these three ints.
> Maybe 3rd time's a charm ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
