ChrisHegarty opened a new issue, #14623: URL: https://github.com/apache/lucene/issues/14623
This issue has been filed to facilitate and capture discussion relating to backward compatibility, specifically around updates to codec formats in minor releases. At Elastic we eagerly adopt and deploy Lucene releases, both major and minor, but here I'm mostly concerned with minor releases. Given our early adoption and deployment we often discover serious bugs that require immediate fixing, e.g. most recently a number of IOOBE in intoBitSet implementations. It's a fact of life that bugs will almost always creep through, and we accept that. What I would like to discuss is if we can improve the upgradeability of minor releases somewhat. A minor release can contain implementation changes, api changes to internal interfaces, new formats, etc. Commonly bugs are found in implementation changes, rather than in new formats. I would like to propose an upgrade model to minor releases that allows to adopt the new minor release without using any new formats for a period of one minor release, after which the old format writer will be removed. Why? Such a model would allow an upgrade of a minor to be separate adopting format changes, for a limited period of time. And then for the format changes to be applied independently of the upgrade. This means that if serious bugs are found in the implementation that it is possible to "rollback" to the prior minor until a bugfix release can be cut. While I'm clearly bias here, I do think that this would be a generally good thing and would hopefully encourage and help others to adopt releases more eagerly too. Specifically: Currently, when a new format is added, the prior one is moved to `org.apache.lucene.backward_codecs.xxx`, and the writer is removed - throws UOE. The writer only exists in the tests for `backwards-codecs`. One concrete proposal is to continue to move the codec to `org.apache.lucene.backward_codecs.xxx`, but retain the writer for one minor release, before it is move to test only. An alternative would be for the consumer to copy the codec format. However, for this to work then we'd need a reliable way to "override" the codec so that the copy (with the writer) would be reliably found. This is currently not possible if deployed with java modules (see https://github.com/apache/lucene/pull/14275). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
