> > The only concern I have with no.2 is that it could be considered an > > “aggressive” adoption of Java 21 - adoption sooner than the ecosystem can > > handle, e.g. are environments in which Lucene is deployed, and their > > transitive dependencies, ready to run on Java 21? By the time we’re ready > > to release 10.0.0, say March 2023, then I expect no issue with this. >
As an open source library from apache software foundation, with no warranty, it is impossible to release too aggressively. Someone doesn't like that we released version 10 because the minimum JDK version won't run on their 486? They just keep using version 9, we didn't hurt them by releasing 10. We can't force them to upgrade to 10 anyway. But on the other hand, it gave a lot of other people a choice. They get the choice to use newer code instead of no choice at all (that code sitting on the shelf for years). Run "git blame lucene/CHANGES.txt" if you think I am crazy. Here's a change I made nearly two years ago, it just sits on the shelf. 84e4b85b094c lucene/CHANGES.txt (Robert Muir 2021-12-07 21:39:13 -0500 14) * LUCENE-10010: AutomatonQuery, CompiledAutomaton, RunAutomaton, RegExp b2e866b70366 lucene/CHANGES.txt (Robert Muir 2021-12-03 19:48:33 -0500 15) classes no longer determinize NFAs. Instead it is the responsibility b2e866b70366 lucene/CHANGES.txt (Robert Muir 2021-12-03 19:48:33 -0500 16) of the caller to determinize. (Robert Muir) I didn't backport that change, not because I am lazy, but because it is the kind of change that deserves to be in a major release (hard to wrap-your-head-around-type-of-change). But I didn't intend for it to sit on the shelf for two years either. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
