I’m confused by what you wrote, and not going to spend my time looking for parallels on logo-dev. IIUC the vote was clearly for moving to java 21, but due to some reasoning in the -1 votes this was rejected: since then a bunch of people have objected to failing the vote. Specifically, which results are obvious, and are the pro or anti java 21 folks starting the haggling?
thanks David Jencks > On May 23, 2025, at 1:05 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
