Howdy, For start, I think Martin assumed the "build time Java requirement for Maven4"?
If so, my "vote" would be like: * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens, until then we just follow LTS), post GA "we adjust to latest LTS on each minor release (so 4.1, 4.2, etc)" * run time: this is the fun part: with Java 21 we already get a warning that `release=8` is deprecated. So, basically that above introduces a hard minimum limit (as given LTS allows). But I think we are with that, as it really makes sense that a Java build (and comprehension bla bla) tool _follow_ Java lifecycle, as things and new features are just flying past us (think JPMS support in Maven), etc. Example for similar setup that we already have: * maven-resolver: build enforces Java 21, but most of modules are still release=8, while some modules being release=11 and some are multi-release JARs (baseline is release=8 but support present for up to 17). * maven-indexer: here, dependency on Lucene 9.x (or 8.x? am unsure) made project 11+, but similarly as in resolver, Java 11+ HttpClient is used, etc. All modules are release=11. In both cases projects require "latest LTS" _for building the project_ (oh, and same is enforced for Maven, "latest Maven" is enforced). This just makes us have less work to figure out why (would) it fail on someone etc... We are sure requirements are fulfilled, and the one who builds it receives "sane" error messages as well, making him able to "fix" (by updating Java and/or Maven versions as needed). Again, all these serves _our benefit_, is not something done "just for fun". My 5 cents T On Tue, Feb 6, 2024 at 12:12 PM Olivier Lamy <ol...@apache.org> wrote: > Personnaly (take it as a vote), I find this a good idea to say: > - 3.x: jdk 8 (whatever someone wants to release some fixes) > - 4.x: jdk 17 > > > On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock <kevin.buntr...@gmail.com> > wrote: > > > > From my modest point of view : glued to old stack projects do not move at > > all. Why move to a new maven version if the one used works? > > > > Furthermore, I'm quite impressed by the number of projects starting in > java > > 21 for clients I was considering really shy new adopters. Java 21 is > here, > > works well, and gets adopted. > > > > Therefore, my vote goes to the current last LTS to run maven 4, a project > > not even released. > > > > Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell <bmarw...@apache.org> a > > écrit : > > > > > > we need to think about companies > > > that pay for old JDK support > > > > > > There was a suggestion on slack that companies could provide "dev and > > > release manager" for Maven 3 and manage the JDK 8 Maven 3 until they > lose > > > interest. This already works well for other projects. > > > > > > Even if no one stands up for volunteering: Maven 3 will continue to > work > > > just fine, even after releases of Maven 4. > > > > > > > > > About the companies who run their own JDK team: > > > Well, they made that a conscious decision. They surely had planned for > > > versions after Java 8. If not, I don't see why we should take their > problem > > > and make it ours. > > > > > > - Ben > > > > > > > > > On Mon, 5 Feb 2024, 23:15 Gary Gregory, <garydgreg...@gmail.com> > wrote: > > > > > > > An interesting question for me is whether we need to think about > > > companies > > > > that pay for old JDK support and how that affects our support for > these > > > old > > > > JDKs. > > > > > > > > Gary > > > > > > > > On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold < > elh...@ibiblio.org> > > > > wrote: > > > > > > > > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau < > > > rmannibu...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > Hi Elliotte, > > > > > > > > > > > Java 11 support is already EOL for most vendor until you go > "premium" > > > > > > flavor which will likely be very few people and most of them > will be > > > > able > > > > > > to pay somebody to backport the needed stuff in custom distro of > > > their > > > > > work > > > > > > if needed anyday so not sure we should consider it. > > > > > > > > > > At least three big tech companies I know of build their own JDKs. > At > > > > > least one, possibly two, ship and support older JDKs for their > > > > > customers. None of them are tied to Oracle and what Oracle is > willing > > > > > to support. If Oracle and all its data went to the great bit > bucket in > > > > > the sky tomorrow, they'd keep right on rolling. It would not even > be a > > > > > speed bump. They don't pay for premium support. They compete to > > > > > provide premium support.* > > > > > > > > > > * There are some caveats here I won't go into for confidentiality > > > > > reasons, but I can say that Azul's business model works. > > > > > > > > > > > On the other side most libraries tend to move forward faster and > if > > > you > > > > > > like big ones, i'll take Spring or JakartaEE as an example - big > user > > > > > base > > > > > > rather than big company$ ;) - and they don't even support Java 11 > > > > > anymore. > > > > > > > > > > Used by big tech customers. Not so much used by big tech companies > > > > > themselves, that tend to run on stacks developed in house over more > > > > > than a decade. > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > elh...@ibiblio.org > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
