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
