There is an interesting parallel here with the what is happening in the logo-dev mailing list: Someone calls for a vote, the results are obvious (count the votes), then it feels like we are back to square one when some starts haggling the whole thing over again. This might not be a bad thing, we are not machines or anywhere near perfect but I just found it interesting.
Gary On Fri, May 23, 2025, 15:34 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > I do not think we can use that as a point otherwise we should go with java > 8. > So question is really do we go with what is current when we do the final or > do we go with a past choice assuming people not upgrading their stack will > upgrade their stack cause maven 4 is too awesome to not upgrade. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > Le ven. 23 mai 2025 à 21:05, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > On Fri, May 23, 2025, 13:40 Benjamin Marwell <bmarw...@apache.org> > wrote: > > > > > Hey, I can totally understand the people voting -1 for the given > reasons. > > > Even with Java 17 support ending in ~15 months FOR PERSONAL USE. > > > There will be a loooooong tail of extended support for money. > > > > > > > > > And how much of this moooooooney will come to Maven maintainers? > > > > Gary > > > > > > > Anyway, my suggestion: > > > Let's do Maven 4.0.0 with Java 17. > > > Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's > > > look again into lifting the runtime requirement to Java 21. > > > By then, community support is about to end and most plugins will be > > > lifted to 17, which will give us a much tighter ecosystem. > > > > > > "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled" > > > > > > Does that work for you? Sounds like a reasonable common ground. > > > It is similar to what has been done with Maven 3, no? > > > > > > - Ben > > > > > > Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen > > > <henn...@schmiedehausen.org.invalid>: > > > > > > > > As a case in point, I am slowly moving the plugins that I maintain ( > > > > https://basepom.github.io/) to Java 17 and 21, even though these are > > > Maven > > > > 3.x.x plugins. I will require projects that adopt those to use 17 or > 21 > > > to > > > > run the build. Which is fine, because I can still deliver Java 8 or > > Java > > > 11 > > > > compatible software even if building on a newer JDK. > > > > > > > > Java 17 is "end of public support" in ~ 15 months. By that time, two > > > newer > > > > LTS versions (21 and 25) will be available. And 21 gives a path to > use > > > > things like FFI which do not exist in 17. > > > > > > > > This decision seems to be too much on the conservative side. Anyone > who > > > > does not want to upgrade Java will not upgrade to Maven 4 anyway. > > > > > > > > -h > > > > > > > > > > > > > > > > On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net > > > > > wrote: > > > > > > > > > Howdy, > > > > > > > > > > very same sentiment over here as well. I am very disappointed with > > the > > > > > outcome. > > > > > > > > > > So, I am curious about folks voting -1... > > > > > > > > > > Is one of them planning to go rogue and surprise us all by doing a > > > > > Maven 4 GA release soon? :D > > > > > > > > > > Thanks > > > > > > > > > > T > > > > > > > > > > > > > > > > > > > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen > > > > > <mfriedenha...@gmx.de.invalid> wrote: > > > > > > > > > > > > I completely second Manfred here: > > > > > > > > > > > > - People who are willing to use Maven 4 soonish should be > > considered > > > > > fast movers. So I guess these are already using Java 21 anyways. > > > > > > - Going from Java 17 to 21 does not require major adaptions if > any > > in > > > > > code in my experience. > > > > > > - New LTS Java 25 comes out this year, so even 21 will not be the > > > shiny > > > > > new version. > > > > > > > > > > > > Mit freundlichen Grüßen > > > > > > Mirko Friedenhagen > > > > > > — > > > > > > Sent from my mobile > > > > > > > > > > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser < > > > manf...@simpligility.ca > > > > > >: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I find this extremely disappointing and also confusing. A > > majority > > > of > > > > > binding and non-binding votes opted FOR adopting Java 21. How can > > this > > > be > > > > > justified with our procedures? > > > > > > > > > > > > > > Here are my arguments for adopting Java 21 that seems to have > > been > > > > > asked for although they are imho obvious. > > > > > > > > > > > > > > * Maven 4 will be a brand new release with many changes. An > > > upgrade of > > > > > the required Java version is already included. Changing that from > 17 > > > to 21 > > > > > does not have that much impact on users. > > > > > > > > > > > > > > * Java 21 is the latest current Java LTS release, and Java 25 > as > > > the > > > > > next LTS will be out in September .. that might even be before > Maven > > 4 > > > > > ships. > > > > > > > > > > > > > > * Java 21 has numerous improvements on top of 17 that making > > > > > programming with it better (and newer versions are even better). > > > > > > > > > > > > > > * Programmers will be less inclined to help a project that uses > > an > > > old > > > > > Java version (17 is 3 years old.. ) and therefore prohibits them > for > > > using > > > > > modern programming styles and usage. > > > > > > > > > > > > > > * Performance of Java 21 is better and it is more suitable to > run > > > on > > > > > containers (which is common for CI and CD systems these days. > > > > > > > > > > > > > > * As a project overall we should strive to provide modern > > powerful > > > > > tooling and that also includes using modern runtime versions and > > taking > > > > > advantage of new features. > > > > > > > > > > > > > > * A later upgrade to Java 21 in in 4.1 for example seem to make > > > sense > > > > > sense for a minor version update. > > > > > > > > > > > > > > * Holding us back to Java 17 means we can not start refactoring > > the > > > > > code to take advantage of features from 18, 19, 20, and 21. > > > > > > > > > > > > > > Beyond that I want to discount the "valid" arguments: > > > > > > > > > > > > > > * Procedurally there is nothing wrong with changing in the RC > > > phase. > > > > > There is no rule about how long that phase is and how many RCs > there > > > should > > > > > be. > > > > > > > > > > > > > > * The new constraints on users only apply if they upgrade to > > Maven > > > 4 > > > > > .. which is completely optional. > > > > > > > > > > > > > > * Even people who voted with -1 said that they would like to > > > upgrade > > > > > and that it would be nice, so what is really holding this back. > > > > > > > > > > > > > > I therefore ask for the conclusion to be reconsidered and > > following > > > > > our majority rules to adopt the raise to Java 21 as requirements > for > > > Maven > > > > > 4 before we release a final version. > > > > > > > > > > > > > > Manfred > > > > > > > > > > > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote: > > > > > > >> Morning everyone, > > > > > > >> first I would like to thank everybody who participated in the > > vote > > > > > [*1] about lifting the required Java version to 21 for Maven 4.0.0. > > > > > > >> > > > > > > >> The vote has ended with the following votes: > > > > > > >> > > > > > > >> -------------- > > > > > > >> Binding votes: > > > > > > >> > > > > > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás > Cservenák, > > > > > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa > > > > > > >> > > > > > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir > > > > > Jaranowski, Hervé Boutemy > > > > > > >> > > > > > > >> > > > > > > >> Non-binding votes: > > > > > > >> > > > > > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo > > > Bourbon, > > > > > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, > Sandra > > > > > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, > > > Daniel B. > > > > > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge > > Solorzano, > > > > > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, > > Thomas > > > > > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico > > > Olivelli > > > > > > >> > > > > > > >> -1: Elliotte Rusty Harold > > > > > > >> > > > > > > >> -------------- > > > > > > >> > > > > > > >> 5 out of 11 binding votes are -1 with valid arguments, > including > > > that > > > > > there is no actual need to upgrade, that (it's too late, as ) we > are > > > > > already in RC phase, and that it might put on new constraints to > > > users. The > > > > > vote was (in line to the vote about lifting Maven 4 to Java 17) a > > > > > "procedural majority vote", meaing a simple majority of binding > votes > > > would > > > > > be enough to considered it to be passed. But due the high number of > > > > > negative votes and brought up arguments, I don't think we should > > ignore > > > > > them but take them into consideration for the benefit of the Maven > > > > > community. Therefore I call the vote to be non successful. We can > > > > > reevaluate in the future, including having a closer look at / > > > discussion > > > > > about the benefits and constraints of raising the Java version. > > > > > > >> > > > > > > >> > > > > > > >> Wish you a happy sunday! > > > > > > >> Matthias > > > > > > >> > > > > > > >> [*1]: > > > > > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr > > > > > > >> > > > > > > >> > > > > > > >> > > > --------------------------------------------------------------------- > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
