[
https://issues.apache.org/jira/browse/LUCENE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131905#comment-14131905
]
Ryan Ernst commented on LUCENE-5940:
------------------------------------
bq. of course i'm not a committer, so i have no final say
Tim, please don't think that we are trying to ignore your concerns. While I
understand your frustration (more work), I don't think the pain you could feel
is really any different than today? There is no specific measurement that goes
into what constitutes enough work for a release, just community sway.
Technically, if someone is willing to do the work (LUCENE-5944), and there are
3 +1's, and more +1's than -1's, a release can happen. I don't mean this as a
threat, I only mean it to demonstrate how arbitrary the process can be, not
guaranteeing you any kind of time between major releases. Because of this, you
could be in the same situation you described with the shorter BWC policy.
The suggested policy would greatly simplify the work needed on the development
side, and give us a clean slate for each major release. And at the same time,
I think this could theoretically extend the ability to upgrade old indexes over
a longer span . The meta tool I have proposed could be the link between all
major versions. All it needs to do is be able to read what version an index
was written with, so it knows the major version (and this ability can be
segregated to that tool, as this should be relatively simple to copy if how to
do that changes). I think this is much more powerful than today's policy,
while at the same time allowing the API to be improved in significant ways
across major releases, compared to now, where it cannot really change without
enormous effort because of the need to continue reading the entire previous
major version.
So from a user perspective, we want to make this work; it is not just for
developers. Your main concerns seem to be about the tool being offline, the
writing special segment metadata, and the network connectivity to grab the old
upgraders.
First, I don't see a way around it being offline; the apis between major
versions could differ in significant ways. But it is no different than if you
had a 3x index today, and we released 5.0 tomorrow: you would first have to
upgrade to a 4x index, why wouldn't you upgrade to 4.99? And that process would
have to be offline, so adding an additional step of first going to 3.99 doesn't
seem unreasonable.
Regarding special metadata, I think most users are just using the default codec
as written. When you use non default setup, it will (most likely always)
require additional work. I understand this pain, but it is pain you have put
upon yourself. But if you already have code for 4x, then upgrading to 4.99
before changing your code to work with 5.0 should not be difficult, since
within a major release the APIs should be stable.
As for network connectivity, it seems like this could just be a packaging
issue? Would it help if each release had the metatool containing the necessary
subjars for each previous release, so that it would not have to download (it
would just make it a bit bigger)?
As developers we need this to happen, to maintain any kind of sanity in our
ability to guarantee compatibility. As users you want backward compatibility to
work as long as possible. I think this would actually serve both purposes, in
a way that is advantageous for both sides.
> 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: [email protected]
For additional commands, e-mail: [email protected]
