I'm with Maarten and Benjamin. We definied 4.0.0 as feature completed
and said we do not want to introduce new features (like Java 21) as we
are already in RC-phase.
I think we should fokus on fixing bugs in 4.0.0 to get a RC5/final 4.0.0
"soon" (TM) - and might it only be the bugs in the Maven Upgrade Tool
(which was initially introduced in RC4) which is a tool we want people
to use. I just filed a new bug when using the tool and saw that there is
at least one more, filed by Karl-Heinz.
After we did 4.0.0 I'm open to introduce the concept of preview features
with 4.1.0 for upcoming Maven versions, similar to the JDK.
Good night and have a good sleep everybody
Matthias
Am 07.10.2025 um 18:29 schrieb Benjamin Marwell:
+1 to what Maarten said. Get it out sooner than later, and I (personally) find
no shame in doing feature releases or even major releases in the distant future.
- Ben
On 7 October 2025 17:34:28 CEST, Maarten Mulders <[email protected]> wrote:
Doing so means we will ship a lot of new features in Maven 4. They will just
not be enabled by default. But this brings a risk of forgetting to put a
particular piece of code (that is only necessary for one of those preview
features) behind a feature flag, thereby enabling it by default and voilà, we
have bugs.
If the fact that we have two branches slows us down, maybe we should consider
investing less in Maven 4.1.0-SNAPSHOT and getting 4.0.0 out of the door first.
Thanks,
Maarten
On 07/10/2025 16:40, Guillaume Nodet wrote:
The point was to avoid maintaining two branches, so the idea is to delete
the maven-4.0.x branch and set the version on master back to 4.0.0-SNAPSHOT.
Le mar. 7 oct. 2025 à 14:42, Maarten Mulders <[email protected]> a
écrit :
Hi all,
Agreed, master should be 4.0.0-SNAPSHOT at least till 4.0.0 is released.
However, enabling new features behind feature flags feels to me as if we
are working around the fact that we're introducing these new features
even when 4.0.0 isn't released yet. They will ship in 4.0.0 (including
any bugs they might include) but users will hopefully not notice.
Shouldn't we do feature flags, experimental new features and all the
like only *after* 4.0.0 was released? For now that would mean the
following changes in branches:
- master becomes temp-this-will-become-4.1-or-whatever
- maven-4.0.x becomes master
And then after 4.0.0 was released,
- temp-this-will-become-4.1-or-whatever becomes master again
Thanks,
Maarten
On 07/10/2025 14:19, Sergey Chernov wrote:
+1
master should be 4.0.0-SNAPSHOT at least till it goes GA, 4.1.0 should be
separate (not master)
On Tue, Oct 7, 2025 at 1:53 PM Romain Manni-Bucau <[email protected]
wrote:
+1 long overdue
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 mar. 7 oct. 2025, 13:51, Sylwester Lachiewicz <[email protected]>
a
écrit :
+1 from me also.
Maybe would be good to release one more rc version before switch?
Sylwester
wt., 7 paź 2025, 13:28 użytkownik Martin Desruisseaux
<[email protected]> napisał:
Le 07/10/2025 à 13:16, Tamás Cservenák a écrit :
In other words, why not have it all on master as 4.0.x instead, and
make certain features (like mixins) "dormant", disabled by default.
Ah sorry, I missed that point. I thought that the plan was to still
have
two branches, with only master renamed 4.1.0 and 4.0.0 renamed master.
Yes, having a single branch with new features in preview mode seems
even
better to me.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
