We cannot do that. We'd have to cut a new release and vote on it. If the goal is to evaluate the release, we need to start voting a 4.0.0, open the vote, if any issue is considered blocking, cancel the vote, fix the issue and cut another 4.0.0 release. If the issue is not blocking, we can do a 4.0.1 a few days or weeks later.
Le lun. 26 mai 2025 à 14:14, Nikita Skvortsov <nikita.skvort...@jetbrains.com.invalid> a écrit : > > I believe having a "Release Candidate" is a good idea > > As long as it is indeed a candidate: a version that is exactly the same as > a release, except for discovered critical issues and version numbers. > I wonder if promoting a candidate to a GA without any code changes requires > modification of existing community processes. > > --- > Nikita Skvortsov > Java Build Tools Team Lead > > JetBrains N.V. | KvK reg. nr. 56460279 > Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands > T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19 > E: nikita.skvort...@jetbrains.com > > > On Sat, 24 May 2025 at 11:12, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Do we have the list of planned API changes? > > Most changes can likely be limited using a "request/response object" > > pattern (so we can add data without breaking instead of passing N > > parameters), new methods dont break, so ultimately we are not worse than > > 3.9.x in terms of stability if we respect that or do respect that in the > > future. > > > > My point is that we can say the exact same reasons to never release v4 > > whereas it is adopted by several people since months now so we should let > > it go and handle bugs as bugs and not as RC which doesnt mean anything > > anymore IMHO. > > > > 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 à 19:32, Benjamin Marwell <bmarw...@apache.org> a > > écrit : > > > > > -1 for release, +1 for rc4. > > > Reason: What Sylwester said, plus Nikita from JetBrains asking nicely. > > > They (JB) would love to see API stability so they can ship an IntelliJ > > > IDEA release in time with Maven 4. > > > This of course applies to all other IDEs. > > > > > > Nikita is on #maven in slack, maybe also subscribed here? idk. > > > > > > Anyway, really strong reasons to do an RC4 first. > > > This should not be hasted. > > > > > > - Ben > > > > > > Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz > > > <slachiew...@gmail.com>: > > > > > > > > I would go for rc4 because we still have API changes after rc3 and our > > > > plugins needs adjustments that could again require another, smaller > > > > changes. > > > > With current state of plugins 4.x they can't be used with latest > > (master) > > > > version so we could offer only 3.x for Maven 4. > > > > Not so big issue for many users but without semi automatic way to move > > > > plugin to new public API we are selling new "untested internally". > > > > > > > > In my opinion, if we could have releases of core plugins based on rc4 > > API > > > > and our CI/CD pipelines runs also under Maven 4 - it would be safer. > > > > > > > > Sylwester > > > > > > > > śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gno...@apache.org> > > > > napisał: > > > > > > > > > Hey Maven Devs, > > > > > > > > > > We're gearing up to release a new version from the master branch. I'm > > > > > thinking we should go for 4.0.0 instead of rc-4. What do you all > > > think? Any > > > > > feedback or ideas on the versioning or release plan? Let’s hear it! > > > > > > > > > > Cheers, > > > > > > > > > > Guillaume > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
