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 > >
