markrmiller commented on issue #13797: URL: https://github.com/apache/lucene/issues/13797#issuecomment-2865097554
Thank you for your question, Vigya. > Will v16 still need to ship the 14-format code? Yes—until a new on-disk break forces `MIN_SUPPORTED_MAJOR` to move again. > Do we ever bump even when nothing broke? No. We bump *only* on an incompatible format change; otherwise, the constant stays put. With the caveat that nothing is promised to the user beyond one major version, and something could come up that a developer decides warrants bumping anyway. Let me try to clarify with a concrete example. The idea is that MIN_SUPPORTED_MAJOR represents "the oldest major version that the current version can read directly" - not a version-by-version compatibility chain. Here's how it would work: Let's say we implement this in Lucene 11 and set MIN_SUPPORTED_MAJOR = 10, meaning Lucene 11 can read Lucene 10 indexes directly. - If Lucene 12 has no breaking index format changes, we'd keep MIN_SUPPORTED_MAJOR = 10 - If Lucene 13 also has no breaking changes, it stays at 10 - If Lucene 14 has no breaking changes, still 10 Now, if Lucene 15 introduces a breaking index format change (e.g., new norms encoding), we'd set MIN_SUPPORTED_MAJOR = 14. This means Lucene 15 can read indexes from version 14 and no older. When Lucene 16 comes along: - If there are no breaking changes, MIN_SUPPORTED_MAJOR remains 14 - If there are breaking changes, we'd bump to MIN_SUPPORTED_MAJOR = 15 So you would need to retain codec read code for versions ≥ MIN_SUPPORTED_MAJOR, but the assumption is this would typically be a low cost for the user benefit. Where it’s not, there is no promise, and MIN_SUPPORTED_MAJOR could be raised even where no break has forced it as a kind of exceptional case. Again, no promises have been made to users. Does that help clarify the proposal? I think your concerns are valid. We would definitely need to ensure this mechanism is well-documented and clearly understood. <subjective_statement> Still, it doesn’t seem like a significant lift given what is already required to make changes and ensure one major release back compat. </subjective_statement> -- 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 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
