As I mentioned in my earlier summary .. the majority of binding and
non-binding votes were for upgrading to 21. I still heard no one
bringing a good reason for ignoring a majority vote because we had a few
objections.
I also find it amazing that we have to justify and vote for upgrading.
Why not the inverse ... we always upgrade by default and we do a vote on
demand only. Then we decide for supporting old, outdated, and hence
often insecure stuff (runtime, dependencies and so on) instead because
... well.. I don't know.
In my opinion we should be upgrading to make the latest LTS a
requirement by default with new releases and have a vote to decide if we
want to support the LTS that is one older.
In any case .. for the current situation I strongly believe we should
upgrade to 21 as majority votes indicate. Maven 4 will be a modern and
new version of a great build and I am still baffled by some thinking it
should work with an old, outdated JDK.
Manfred
On 2025-05-24 10:52 a.m., Karl Heinz Marbaise wrote:
Hi,
greatly summarized.
Thank you for that.
Kind regards
Karl Heinz Marbaise
On 24.05.25 19:21, Michael Bien wrote:
On 5/24/25 15:33, Elliotte Rusty Harold wrote:
On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák
<ta...@cservenak.net> wrote:
... aaand because some company/ies does/do that,
we as an open source project/forget need/must stick to it?
The claim that we must move our JDK version forward because Java
8/11/17 is not supported is fallacious. It is based on a false
premise.
If you want to upgrade the minimum Java version, you need a better
reason than that. I haven't yet heard a reason strong enough to
convince me. Others have other opinions.
I would be curious what the strategy would have been if maven 4 would
have decided to stay on JDK 8.
Wait till 2030 and then throw maven away and build something new? Do
one big jump from 8 to 2x
and hope the community would accept it? Hope that vendors would keep
supporting some slightly newer
JDK versions beyond 2030 to get a few extra years out of it?
If vendors would not stop supporting JDKs, maven would have 7 JDK
versions to support in 2030 - this is
quite a test matrix (not to mention the wasted resources).
Trying to keep the delta between 'min' and 'current' constant sounds
like the pragmatic approach for
projects which plan to stick around. In fact many did and introduced
some easy to remember, forward
looking rule like "our latest major version supports 2 LTS + current".
The crazy part about this discussion to me is that maven already has
a solution for this.
Maven 3 exists, runs on JDK 8 and is supported as long as the
community wants to support it.
Maven 4 could even do a RC more and be JDK 25+ without influencing
anyone on JDK 8.
So basically, all we did so far was "waste of resources"
as Java 8 is there to stay, at least until 2030, right?
IMHO, yes. I would much rather people invested their time into fixing
Maven bugs and improving the health of the codebase rather than
continuously migrating code from one Java version to the next.
Bugfixes and refactoring are luckily not mutually exclusive and are
just regular project maintenance
tasks.
The cumulative time spent writing JDK version discussion mails is
probably already more than the
review of a fictional global JDK 17->21 migration PR would take.
(that is another reason why many
projects came up with an easy to remember min-version rule rather
than having to repeat this
kind of threads every few years)
There is also no time pressure behind language level cleanups. They
can (and often should) happen
incrementally, as needed, without disrupting any other tasks. The
point in time when the min
requirements are bumped is only the starting point which unlocks more
cleanup options - the rest
follows organically.
That's
life with a volunteer project though. Developers are going to do what
they find fun rather than delivering user value.
no fun allowed while producing value ;)
I could flip the argument and say that trying to reduce aspects which
are generally perceived as not-fun,
probably creates value for everyone over the long term, including
users. Esp in open source projects
which rely on motivated developers spending some of their free time
(or carefully negotiated work-time)
helping to maintain it.
what lucky situation to be in when developers perceive modern APIs /
language idioms / cleaner code as
more fun :)
(btw: is it ok to use vote threads for discussions?)
best regards,
-mbien
---------------------------------------------------------------------
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
