[
https://issues.apache.org/jira/browse/LUCENE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130270#comment-14130270
]
Ryan Ernst commented on LUCENE-5940:
------------------------------------
bq. the problem with the upgrade tool approach is that it doesn't scale to
clusters with large numbers of indexes.
Can you elaborate more? Your example of 50 indexes spread across many machines
doesn't make me understand how it would be difficult to run this tool. I see
the steps as:
# Install the newest lucene (you would already have to do this)
# Run the meta tool. This will download the necessary indexupgrader self
contained jar for previous releases, and follow the upgrade path to get to the
current release.
bq. are there technical issues here i'm unaware of beyond creating and
maintaining the backwards compat tests?
I'd just like to reiterate what Robert said. Have you looked at how much code
is involved in maintaining backcompat? Just for the current 3x and 4x, it is
enormous. And you can't assume the codec API will stay the same. Changing the
codec api means updating old codecs in some way that they still work as
expected (Robert's example with updateable DV). Minimizing that effort for a
developer allows more rapid experimentation and iteration.
The advantage to the indexupgrader tool Uwe described is it is completely self
contained. All the old codecs are there, and when that jar was created, it was
tested thoroughly with the upgrade paths it supports. But those old codecs and
upgrade paths don't have to be in the current codebase, which makes changing
the current code easier.
> change index backwards compatibility policy.
> --------------------------------------------
>
> Key: LUCENE-5940
> URL: https://issues.apache.org/jira/browse/LUCENE-5940
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> Currently, our index backwards compatibility is unmanageable. The length of
> time in which we must support old indexes is simply too long.
> The index back compat works like this: everyone wants it, but there are
> frequently bugs, and when push comes to shove, its not a very sexy thing to
> work on/fix, so its hard to get any help.
> Currently our back compat "promise" is just a broken promise, because we
> cannot actually guarantee it for these reasons.
> I propose we scale back the length of time for which we must support old
> indexes.
--
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
