[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org