javanna commented on issue #14623: URL: https://github.com/apache/lucene/issues/14623#issuecomment-2866023747
I read your comments and I am also nervous about extending the compatibility that Lucene currently offers. I totally get the point around backporting after baking time in main, and I wonder if and how we would have caught this specific bug, for what it's worth, had we waited backporting the change that caused it. I don't know the answer to this question :) Taking a step back, I have some high-level thoughts, and I am playing a bit devil's advocate, so bear with me here: we at Elastic ship to production Lucene releases in matter of days after they are out. We did that with Lucene 10.0, and we do that with every minor release. I love that we do that, and I hope that more users do so over time. Whenever we find a bug after the roll-out, it is extremely painful to investigate it, find a work-around, fix it upstream under time pressure, while users experience potential disruptions. I would hate if we ended up holding off the roll-out to prod due to fear of finding bugs and to avoid disruptions. Also, that would not help much currently as the roll-out to prod is exactly what helps us find bugs :) we can certainly broaden testing etc. but we all know certain things come up only in production. The time pressure derives from the lack of ability to downgrade to the previous Lucene minor. If we were able to do that, we would do so, and have then time to investigate and do all that's needed, without the time pressure. Like Chris said, I would not consider a downgrade through major releases, but I wonder if there's some option to consider to move in that direction over time. I like the idea of isolating/containing formats changes for instance. And again, I totally see the compatibility burden, I am torn as well, but I think it's an important problem, and tackling it somehow may even help users upgrade faster if they know they have a way out potentially? Would that not be in the interest of the project (although to be weighed against the cons of the compatibility burden)? -- 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
