Hi Robert, > On 6 Nov 2023, at 12:24, Robert Muir <rcm...@gmail.com> wrote: > >> … >> 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. > > The problem is worse, historically jdk version X isn't adopted as a > minimum until it is already EOL. And the lucene major versions take an > eternity to get out there, code just sits in "main" branch for years > unreleased to nobody. It is really discouraging as a contributor to > contribute code that literally sits on the shelf for years, for no > good reason at all.
Agreed. I also feel discouraged by this approach too, and also wanna avoid the “backport the world”, since it’s counterproductive. > So why delay? > > The argument of "moving sooner than ecosystem can handle" is also > bogus in the same way. You mean versus the code sitting on the shelf > and being released to nobody? Yes - sitting on the shelf is no good to anyone. Ok, what I’m hearing are good arguments for releasing 10.0.0 *now*, with a Java 17 minimum - this is what is in _main_ today. If we do that, then we can follow up with _main_ later (after the 10.x branch is created). That is, 1) bump _main_ to Java 21, and 2) decide when a Lucene 11 is to be released (I would to see Lucene 11 ~1yr after Lucene 10). This is Uwe’s proposal, earlier in this thread. -Chris. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
