+1 to a 10.0 on JDK17. There is no "agreement" anywhere to follow a 2-year cadence for major versions, even if that's been a pattern. Adopting a new JDK with clear benefits or getting off an EOL JDK should be valid arguments for considering a new major. If downstream wants to keep supporting 9.10.y into eternity after our 11.0 rlease, then it's open source :)
Jan > 6. nov. 2023 kl. 13:40 skrev Chris Hegarty > <christopher.hega...@elastic.co.INVALID>: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
