You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Matthias Bünger <mb...@apache.org> on 2026/02/12 17:10:22 UTC
[Discussion] What needs to be done for 4.0.0 GA?
Good evening everybody,
last week a small number of commiter and PMC had a chat about the
current situation about Maven 4.0.0.
Nobody of the people attended was aware of any outstanding blocking
issues, but also nobody could precicle say what else needs to be done
for a GA release. As a result we collected some points on a wiki page [1].
Today Benjamin asked me to send a mail to the list, to gather feedback,
if we missed anything . Do you agree with the points on the list or do
you see any (and if yes, which) blocker that needs to be done, before we
can consider a 4.0.0 GA?
Please note: This discussion should focus on "What's need to be done for
4.0.0". It's not about discussions about will there new RC or was RC5
the last RC. This can be discussed when we have a complete (as possible)
list of TO-DO's. So please avoid to restart any discussion about
alpha/beta/RC versions in this thread. What happend, happend (including
new features, like Maven Update tool, during RC phase) - thank you.
Matthias
[1]:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Martin Desruisseaux via dev <de...@maven.apache.org>.
Hello Mathias
Thanks for creating this list. On the "blockers with no known
workaround" item, I have this pull request which could be merged if
approved. It applies only to projects using module source hierarchy.
Classical Maven projects are not impacted, so this change should not be
visible to the vast majority of current users. But it is necessary for
continuing the work on module hierarchy at the Maven JAR plugin level.
https://github.com/apache/maven/pull/11639
And the following pull request is needed for resources management.
Again, it applies only to projects using module source hierarchy. Maybe
more important, it also checks that a modular project is not malformed.
I think that it is better to be strict at GA release time rather than
making the checks stricter in a subsequent release, which could be a
compatibility break:
https://github.com/apache/maven/pull/11700
Thanks,
Martin
Le 12/02/2026 à 18:10, Matthias Bünger a écrit :
> Good evening everybody,
> last week a small number of commiter and PMC had a chat about the
> current situation about Maven 4.0.0.
> Nobody of the people attended was aware of any outstanding blocking
> issues, but also nobody could precicle say what else needs to be done
> for a GA release. As a result we collected some points on a wiki page
> [1].
>
> Today Benjamin asked me to send a mail to the list, to gather
> feedback, if we missed anything . Do you agree with the points on the
> list or do you see any (and if yes, which) blocker that needs to be
> done, before we can consider a 4.0.0 GA?
>
> Please note: This discussion should focus on "What's need to be done
> for 4.0.0". It's not about discussions about will there new RC or was
> RC5 the last RC. This can be discussed when we have a complete (as
> possible) list of TO-DO's. So please avoid to restart any discussion
> about alpha/beta/RC versions in this thread. What happend, happend
> (including new features, like Maven Update tool, during RC phase) -
> thank you.
>
> Matthias
>
> [1]:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Maarten Mulders <mt...@apache.org>.
Hi Matthias, Benjamin,
Thanks for creating such a list. With large and much anticipated
releases like these, I think it's good to have a plan so we will not
forget the less-obvious things.
As a point to consider, would it make sense to contact ASF Infra
upfront? As far as I know, they administer some Jenkins build machines.
If so, they might want to equip those with the upcoming Maven 4.
Thanks,
Maarten
On 12/02/2026 18:10, Matthias Bünger wrote:
> Good evening everybody,
> last week a small number of commiter and PMC had a chat about the
> current situation about Maven 4.0.0.
> Nobody of the people attended was aware of any outstanding blocking
> issues, but also nobody could precicle say what else needs to be done
> for a GA release. As a result we collected some points on a wiki page [1].
>
> Today Benjamin asked me to send a mail to the list, to gather feedback,
> if we missed anything . Do you agree with the points on the list or do
> you see any (and if yes, which) blocker that needs to be done, before we
> can consider a 4.0.0 GA?
>
> Please note: This discussion should focus on "What's need to be done for
> 4.0.0". It's not about discussions about will there new RC or was RC5
> the last RC. This can be discussed when we have a complete (as possible)
> list of TO-DO's. So please avoid to restart any discussion about alpha/
> beta/RC versions in this thread. What happend, happend (including new
> features, like Maven Update tool, during RC phase) - thank you.
>
> Matthias
>
> [1]: https://cwiki.apache.org/confluence/display/MAVEN/
> Maven+4.0.0+GA+checklist
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Fri, Feb 13, 2026 at 5:28 PM Henning Hoefer
<he...@device-insight.com> wrote:
> Maven 4.0 improves a lot of things, it absolutely should be released. If
> the APIs aren't perfect, there's always a Maven 4.1. And if bigger things
> need fixing, just make a Maven 5. But not releasing anything doesn't help
> anybody.
Not all issues are created equal.There are things we can add later if
we don't have them now, but more important are the things we can't
change after we ship them. That includes essentially all public API.
Better not to have it at this stage than to have the wrong thing, and
we have way too many of the wrong things in the Maven 4 codebase. A
lot of this is fix it now or live with the pain for likely as long as
Maven exists or we do, whichever comes first.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Henning Hoefer <he...@device-insight.com>.
Well, *my* pet-peeve regarding transitive dependencies (#10
<https://github.com/apache/maven/issues/10786>786
<https://github.com/apache/maven/issues/10786>, formerly known as MNG-8099
<https://issues.apache.org/jira/browse/MNG-8099?redirect=false>) is also
not in, but I would never think that Maven 4 should be delayed because of
that. :-)
If you want to wait until every last issue is resolved, you're simply never
going to ship anything. Another old saying: Perfect is the enemy of good.
Software, especially collaborative efforts, will *always* be "undergrad
papers". And that's how open source (and science) moves forward.
Maven 4.0 improves a lot of things, it absolutely should be released. If
the APIs aren't perfect, there's always a Maven 4.1. And if bigger things
need fixing, just make a Maven 5. But not releasing anything doesn't help
anybody.
Just my 0,02€...
Now back to the actual topic of this thread:
I'm missing some step for verification of the new release "in the wild",
with as many different projects as possible.
Aren't there any statistics on how often the RCs got used?
- Henning
Am Fr., 13. Feb. 2026 um 16:54 Uhr schrieb Elliotte Rusty Harold <
elharo@ibiblio.org>:
> IMHO Maven 4.0 is not close to ready for release. The most serious
> issue is the change of namespace. That's a major mistake that will
> cause large problems for developers, especially those who use tools
> other than Maven itself.
>
> Second most serious issue is finalization of APIs. @Experimental
> features need to be committed to or removed.
>
> Similarly APIs have been deprecated but not documented with
> replacement. That also needs to be finished.
>
> Finally much of the new API is unnecessarily complex with unneeded
> separation of basic functionality like URLNormalizer into separate
> interfaces, implementations, services, and default implementations
> when all that’s needed is one single class with a few static methods.
>
> All of this can and should be fixed before release. Much of it cannot
> be fixed after release.
>
> There’s an old saying about undergraduate papers: they’re never
> finished, just submitted when the deadline comes. That’s what’s going
> on here. Maven 4 isn’t close to a finished product, and it’s not clear
> it has the resources or will to be finished, so there’s an urgency to
> push something out the door, ready or not. However, pushing it out in
> an unfinished state risks doing severe damage to the developer
> community and Maven’s reputation. It is better to ship nothing than to
> ship a half-baked product, discouraging as that is to the people who
> have been working on it.
>
> On Thu, Feb 12, 2026 at 5:10 PM Matthias Bünger <mb...@apache.org>
> wrote:
> >
> > Good evening everybody,
> > last week a small number of commiter and PMC had a chat about the
> > current situation about Maven 4.0.0.
> > Nobody of the people attended was aware of any outstanding blocking
> > issues, but also nobody could precicle say what else needs to be done
> > for a GA release. As a result we collected some points on a wiki page
> [1].
> >
> > Today Benjamin asked me to send a mail to the list, to gather feedback,
> > if we missed anything . Do you agree with the points on the list or do
> > you see any (and if yes, which) blocker that needs to be done, before we
> > can consider a 4.0.0 GA?
> >
> > Please note: This discussion should focus on "What's need to be done for
> > 4.0.0". It's not about discussions about will there new RC or was RC5
> > the last RC. This can be discussed when we have a complete (as possible)
> > list of TO-DO's. So please avoid to restart any discussion about
> > alpha/beta/RC versions in this thread. What happend, happend (including
> > new features, like Maven Update tool, during RC phase) - thank you.
> >
> > Matthias
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 14 févr. 2026 à 22:56, Martin Desruisseaux <
martin.desruisseaux@geomatys.com> a écrit :
> Le 14/02/2026 à 21:19, Romain Manni-Bucau a écrit :
>
> > Side note: while maven 5 itself could use JPMS for its api + core +
> > resolver modules (and likely nothing else), the rest must not use JPMS
> > by design and stay user friendly (extensions + plugins)
>
> It is a little bit off-topic, but just for information: I hope to
> propose a full modularisation of Maven 5, including core and all
> plugins. I have see in the past arguments saying that we cannot discover
> plugins at runtime using JPMS. But this not true: it is just that the
> way to do that is different (we need to use java.lang.ModuleLayer).
>
This is not the blocker, this part is easy, the blocker is that a lot of
mojo will never embrace JPMS so we must run without JPMS at all extensions
and plugins (doesnt mean we can't run a JPMS plugin, OSGi does it for ex,
but means this must not be a requirement).
>
> Anyway, this is probably not a topic before a few years.
>
> Martin
>
>
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Martin Desruisseaux via dev <de...@maven.apache.org>.
Le 14/02/2026 à 21:19, Romain Manni-Bucau a écrit :
> Side note: while maven 5 itself could use JPMS for its api + core +
> resolver modules (and likely nothing else), the rest must not use JPMS
> by design and stay user friendly (extensions + plugins)
It is a little bit off-topic, but just for information: I hope to
propose a full modularisation of Maven 5, including core and all
plugins. I have see in the past arguments saying that we cannot discover
plugins at runtime using JPMS. But this not true: it is just that the
way to do that is different (we need to use java.lang.ModuleLayer).
Anyway, this is probably not a topic before a few years.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well my view is that maven 3 was 100% wrong since it didn't have any API
and lived years, it did break API and people survived.
That you are used to old style API which will be totally inconsistent with
the IoC (static utilities) or modern over engineered design it is mainly a
habit thing and I our community is wide enough to be sure to not converge
there.
So overall if the API works and being said we are always free to keep
adding new API, potentially simpler services (please never anything static,
it is too bothersome to override/extends and shouts ourselves in the feet
in terms of design).
So long story short, no block.
Side note: while maven 5 itself could use JPMS for its api + core +
resolver modules (and likely nothing else), the rest must not use JPMS by
design and stay user friendly (extensions + plugins) so JPMS can be a bad
bet for a redesign but it doesn't change the fact services design is better
than in maven 3 and can be enhanced without any breaking change.
=> all good to release on that aspect
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>
Javaccino founder (Java/.NET service - contact via linkedin)
Le sam. 14 févr. 2026 à 11:10, Martin Desruisseaux via dev <
dev@maven.apache.org> a écrit :
> Hello all
>
> I also question whether the public API really needs so many services and
> interfaces. But I think that a compatibility break in Maven 5 may be
> unavoidable anyway, even if we didn't introduced any new API in Maven 4
> compared to Maven 3. One reason is because in my understanding, the
> classes in the `org.eclipse.aether` packages are practically public API.
> But those classes duplicate Maven classes: a `Dependency` class exists
> in Aether packages, in Maven API, in Maven model, and more. Debugging
> Maven is tedious: an Aether Dependency is wrapped in a Maven Dependency,
> then unwrapped when we need to invoke an Aether API, then wrapped again,
> etc. Consequently, following step-by-step in a debugger is confusing. We
> could improve by merging the Aether classes with Maven implementation
> classes, but it would break compatibility for plugins that use the
> Aether classes. Said otherwise, we inherited from Maven 3 a technical
> debt that cannot be resolved (in my understanding) without compatibility
> break. Maven 4 is not breaking that compatibility yet, but we may
> consider whether Maven 5 should break it.
>
> That said, I do have some concerns about Maven 4 API:
>
> * I share with Elliotte the impression that we have gone a little bit
> too far in separating everything in interfaces.
> * I think that the implementations have too many public classes. I
> think that it would have been safer to keep all implementations
> private or package-private by default, and change to protected or
> public access only when it appears to be needed.
> * We didn't anticipated records in the names of the methods declared
> in interfaces. This is unfortunate since records could simplify a
> lot all the places where Maven uses the "for = foo.withBar(bar)"
> pattern, and probably improves performance as well.
>
> Maven 4 wasn't designed with records from the ground because the upgrade
> from Java 8 to Java 17 came too late in Maven 4 history (most of Maven
> API was already in place when the upgrade was done). However, even if we
> anticipated records, we would be forced to implement the "for =
> foo.withBar(bar)" pattern anyway because we cannot use JEP 468 (Derived
> Record Creation) yet. Removing that pattern in Maven 5 (if we choose to
> do so) would be another compatibility break.
>
> Finally, after completion of the work in Maven 4 for better support of
> Java modules, I hope to propose a modularisation of Maven 5 itself.
> Again it may bring simplifications such as removing the need for
> plexus-classworlds. But it may be another source of incompatibility.
>
> In summary, while I agree that there are issues with Maven 4 API, those
> issues may be nuanced in the perspective of an hardly avoidable
> compatibility break in (maybe) Maven 5 anyway.
>
> Martin
>
>
> Le 13/02/2026 à 16:53, Elliotte Rusty Harold a écrit :
> > IMHO Maven 4.0 is not close to ready for release. The most serious
> > issue is the change of namespace. That's a major mistake that will
> > cause large problems for developers, especially those who use tools
> > other than Maven itself.
> >
> > Second most serious issue is finalization of APIs. @Experimental
> > features need to be committed to or removed.
> >
> > Similarly APIs have been deprecated but not documented with
> > replacement. That also needs to be finished.
> >
> > Finally much of the new API is unnecessarily complex with unneeded
> > separation of basic functionality like URLNormalizer into separate
> > interfaces, implementations, services, and default implementations
> > when all that’s needed is one single class with a few static methods.
> >
> > All of this can and should be fixed before release. Much of it cannot
> > be fixed after release.
> >
> > There’s an old saying about undergraduate papers: they’re never
> > finished, just submitted when the deadline comes. That’s what’s going
> > on here. Maven 4 isn’t close to a finished product, and it’s not clear
> > it has the resources or will to be finished, so there’s an urgency to
> > push something out the door, ready or not. However, pushing it out in
> > an unfinished state risks doing severe damage to the developer
> > community and Maven’s reputation. It is better to ship nothing than to
> > ship a half-baked product, discouraging as that is to the people who
> > have been working on it.
>
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Martin Desruisseaux via dev <de...@maven.apache.org>.
Hello all
I also question whether the public API really needs so many services and
interfaces. But I think that a compatibility break in Maven 5 may be
unavoidable anyway, even if we didn't introduced any new API in Maven 4
compared to Maven 3. One reason is because in my understanding, the
classes in the `org.eclipse.aether` packages are practically public API.
But those classes duplicate Maven classes: a `Dependency` class exists
in Aether packages, in Maven API, in Maven model, and more. Debugging
Maven is tedious: an Aether Dependency is wrapped in a Maven Dependency,
then unwrapped when we need to invoke an Aether API, then wrapped again,
etc. Consequently, following step-by-step in a debugger is confusing. We
could improve by merging the Aether classes with Maven implementation
classes, but it would break compatibility for plugins that use the
Aether classes. Said otherwise, we inherited from Maven 3 a technical
debt that cannot be resolved (in my understanding) without compatibility
break. Maven 4 is not breaking that compatibility yet, but we may
consider whether Maven 5 should break it.
That said, I do have some concerns about Maven 4 API:
* I share with Elliotte the impression that we have gone a little bit
too far in separating everything in interfaces.
* I think that the implementations have too many public classes. I
think that it would have been safer to keep all implementations
private or package-private by default, and change to protected or
public access only when it appears to be needed.
* We didn't anticipated records in the names of the methods declared
in interfaces. This is unfortunate since records could simplify a
lot all the places where Maven uses the "for = foo.withBar(bar)"
pattern, and probably improves performance as well.
Maven 4 wasn't designed with records from the ground because the upgrade
from Java 8 to Java 17 came too late in Maven 4 history (most of Maven
API was already in place when the upgrade was done). However, even if we
anticipated records, we would be forced to implement the "for =
foo.withBar(bar)" pattern anyway because we cannot use JEP 468 (Derived
Record Creation) yet. Removing that pattern in Maven 5 (if we choose to
do so) would be another compatibility break.
Finally, after completion of the work in Maven 4 for better support of
Java modules, I hope to propose a modularisation of Maven 5 itself.
Again it may bring simplifications such as removing the need for
plexus-classworlds. But it may be another source of incompatibility.
In summary, while I agree that there are issues with Maven 4 API, those
issues may be nuanced in the perspective of an hardly avoidable
compatibility break in (maybe) Maven 5 anyway.
Martin
Le 13/02/2026 à 16:53, Elliotte Rusty Harold a écrit :
> IMHO Maven 4.0 is not close to ready for release. The most serious
> issue is the change of namespace. That's a major mistake that will
> cause large problems for developers, especially those who use tools
> other than Maven itself.
>
> Second most serious issue is finalization of APIs. @Experimental
> features need to be committed to or removed.
>
> Similarly APIs have been deprecated but not documented with
> replacement. That also needs to be finished.
>
> Finally much of the new API is unnecessarily complex with unneeded
> separation of basic functionality like URLNormalizer into separate
> interfaces, implementations, services, and default implementations
> when all that’s needed is one single class with a few static methods.
>
> All of this can and should be fixed before release. Much of it cannot
> be fixed after release.
>
> There’s an old saying about undergraduate papers: they’re never
> finished, just submitted when the deadline comes. That’s what’s going
> on here. Maven 4 isn’t close to a finished product, and it’s not clear
> it has the resources or will to be finished, so there’s an urgency to
> push something out the door, ready or not. However, pushing it out in
> an unfinished state risks doing severe damage to the developer
> community and Maven’s reputation. It is better to ship nothing than to
> ship a half-baked product, discouraging as that is to the people who
> have been working on it.
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
IMHO Maven 4.0 is not close to ready for release. The most serious
issue is the change of namespace. That's a major mistake that will
cause large problems for developers, especially those who use tools
other than Maven itself.
Second most serious issue is finalization of APIs. @Experimental
features need to be committed to or removed.
Similarly APIs have been deprecated but not documented with
replacement. That also needs to be finished.
Finally much of the new API is unnecessarily complex with unneeded
separation of basic functionality like URLNormalizer into separate
interfaces, implementations, services, and default implementations
when all that’s needed is one single class with a few static methods.
All of this can and should be fixed before release. Much of it cannot
be fixed after release.
There’s an old saying about undergraduate papers: they’re never
finished, just submitted when the deadline comes. That’s what’s going
on here. Maven 4 isn’t close to a finished product, and it’s not clear
it has the resources or will to be finished, so there’s an urgency to
push something out the door, ready or not. However, pushing it out in
an unfinished state risks doing severe damage to the developer
community and Maven’s reputation. It is better to ship nothing than to
ship a half-baked product, discouraging as that is to the people who
have been working on it.
On Thu, Feb 12, 2026 at 5:10 PM Matthias Bünger <mb...@apache.org> wrote:
>
> Good evening everybody,
> last week a small number of commiter and PMC had a chat about the
> current situation about Maven 4.0.0.
> Nobody of the people attended was aware of any outstanding blocking
> issues, but also nobody could precicle say what else needs to be done
> for a GA release. As a result we collected some points on a wiki page [1].
>
> Today Benjamin asked me to send a mail to the list, to gather feedback,
> if we missed anything . Do you agree with the points on the list or do
> you see any (and if yes, which) blocker that needs to be done, before we
> can consider a 4.0.0 GA?
>
> Please note: This discussion should focus on "What's need to be done for
> 4.0.0". It's not about discussions about will there new RC or was RC5
> the last RC. This can be discussed when we have a complete (as possible)
> list of TO-DO's. So please avoid to restart any discussion about
> alpha/beta/RC versions in this thread. What happend, happend (including
> new features, like Maven Update tool, during RC phase) - thank you.
>
> Matthias
>
> [1]:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Discussion] What needs to be done for 4.0.0 GA?
Posted by Matthias Bünger <mb...@apache.org>.
Hi all,
thank you all for the responses. I added missing To-Dos from the mailing
list to the wiki page [1]. After that I tried to group points by topic.
As a conclusion, I identified the following topics we work is needed for
4.0.0.
1. Blocking issues ("bugs")
2. Maven 4 API
3. Maven 4 Namespace
4. Compatibility of 3rd party tools and infrastructure services
5. Compatibility of 3rd party "library projects"
I personally see a gap between the first three and the last two, as the
last two depend on the state/decisions of the first three (esp. 2+3). I
suggest to decide on them in either Maarten's discussion thread [2] or a
vote or somehow else. So please head over to the discussion thread and
keep this thread here clean for responses of new things poping up or
change state of existing things.
Matthias
P.S. I won't be active very much in March, but will try to keep an eye
on this thread.
[1]
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
[2] https://lists.apache.org/thread/f012nxx8msltcp06f2h848n1rkowl4kj
Am 12.02.2026 um 18:10 schrieb Matthias Bünger:
> Good evening everybody,
> last week a small number of commiter and PMC had a chat about the
> current situation about Maven 4.0.0.
> Nobody of the people attended was aware of any outstanding blocking
> issues, but also nobody could precicle say what else needs to be done
> for a GA release. As a result we collected some points on a wiki page
> [1].
>
> Today Benjamin asked me to send a mail to the list, to gather
> feedback, if we missed anything . Do you agree with the points on the
> list or do you see any (and if yes, which) blocker that needs to be
> done, before we can consider a 4.0.0 GA?
>
> Please note: This discussion should focus on "What's need to be done
> for 4.0.0". It's not about discussions about will there new RC or was
> RC5 the last RC. This can be discussed when we have a complete (as
> possible) list of TO-DO's. So please avoid to restart any discussion
> about alpha/beta/RC versions in this thread. What happend, happend
> (including new features, like Maven Update tool, during RC phase) -
> thank you.
>
> Matthias
>
> [1]:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org