That definition makes a lot of sense to me. If we would adhere to it, we should discipline ourselves after "a" next RC and *not* accept any code changes *except* for fixing critical uses.

I think there have been too many changes since last RC to cut a 4.0.0 today.


Maarten

On 26/05/2025 14:14, Nikita Skvortsov wrote:
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






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to