I like all 5 cents 😀 Gary
On Tue, Feb 6, 2024, 7:00 AM Tamás Cservenák <ta...@cservenak.net> wrote: > 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 > > > > >
