You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2022/04/07 08:17:56 UTC
We need to lay down strategy
... to not dissipate and reduce our (effort) losses :)
Howdy,
In short, I think we can agree on this sentence:
"we need to get rid of maven 3.8.x as fast as possible, release maven 3.9.x
and once out, keep it on regression fixes until maven 4 is ready".
# Get rid of Maven 3.8.x
Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
must:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
There are some other issues "affects 3.8.5" but I don't see them as
blockers (but please argue if you disagree):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
Out of them:
MNG-7432 [REGRESSION] Dependencies from profile not picked up via
-P<profileName>
Must be fixed (PR merge pending)
MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
can lock each other
Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
this looks too vague to me, as Guillaume PR for sure cannot deadlock two
JVMs.... (it uses in-JVM locks).
MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
Anyone? Unsure what is happening here, also how are these "new classes in
3.8.5"?
MNG-7441 Update Version of Logback to Address CVE-2021-42550
We should do this, as we plan to keep 3.8.x on the shelf for a while.
Hence, we will get more and more reports like these from end users. Let's
cut it from the root.
MNG-7438 add execution id to "Configuring mojo xxx with basic configurator"
debug message
IMHO: nope
MNG-4917 Profile not active even though it has activeByDefault set to true
IMHO: nope -- this issue is 12 years old!
MNG-7429 The classloader containing build extensions should be used
throughout the build
IMHO nope: (unless regression from some 3.8.x)
MNG-7448 if we delete bin directory in apache-maven/src, we can not find
because git has ignore it .
IMHO nope: ???
MNG-7439 Make fields of CliRequest protected
IMHO nope
So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
out, forget it, no more fixes (unless some really serious regression is
reported, but otherwise nada).
# Maven 3.9.x
IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
ready to merge) as then Maven will get much much more goodness (not only
1.7.x locking, but also extensible checksums, smart checksums, provided
checksums, DF and BF collector, ability for signature resolution, proper
ignores for artifacts not needed checksums). To make smart checksums usable
for maven, http transport is needed as well (PR as it is no go, it needs to
make Wagon still remain default transport, will fix that). Or, we could
make it as is, and then if anyone has issues or badly wants Wagon, there is
a command line to make it so....
So, IMHO, for 3.9.x
- Port fixes that we decide to be done in 3.8.6 naturally
- Use resolver 1.8.0 (wait for it, one remaining PR merge, released
hopefully very soon)
- Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
default or not. Also this PR would get rid of shaded stuff as well.
And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
some serious regression falls in).
# Maven 4
Guillaume already did a huge amount of work that he probably needs help on,
so help him to wrap up things....
WDYT?
T
Re: We need to lay down strategy
Posted by Hervé BOUTEMY <he...@free.fr>.
I love that plan against 3.8.x, 3.9.x and 4
I did not really track details from 3.8.x, then I let others define what needs
to get in 3.8.6 to stabilize and let us focus on 3.9
Regards,
Hervé
Le jeudi 7 avril 2022, 10:17:56 CEST Tamás Cservenák a écrit :
> ... to not dissipate and reduce our (effort) losses :)
>
> Howdy,
>
> In short, I think we can agree on this sentence:
> "we need to get rid of maven 3.8.x as fast as possible, release maven 3.9.x
> and once out, keep it on regression fixes until maven 4 is ready".
>
> # Get rid of Maven 3.8.x
>
> Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
> must:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resol
> ution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%20pri
> ority%20DESC%2C%20updated%20DESC
>
> There are some other issues "affects 3.8.5" but I don't see them as
> blockers (but please argue if you disagree):
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resol
> ution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%20BY%
> 20priority%20DESC%2C%20updated%20DESC
>
> Out of them:
>
> MNG-7432 [REGRESSION] Dependencies from profile not picked up via
> -P<profileName>
> Must be fixed (PR merge pending)
>
> MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
> can lock each other
> Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
> Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
> this looks too vague to me, as Guillaume PR for sure cannot deadlock two
> JVMs.... (it uses in-JVM locks).
>
> MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
> Anyone? Unsure what is happening here, also how are these "new classes in
> 3.8.5"?
>
> MNG-7441 Update Version of Logback to Address CVE-2021-42550
> We should do this, as we plan to keep 3.8.x on the shelf for a while.
> Hence, we will get more and more reports like these from end users. Let's
> cut it from the root.
>
> MNG-7438 add execution id to "Configuring mojo xxx with basic configurator"
> debug message
> IMHO: nope
>
> MNG-4917 Profile not active even though it has activeByDefault set to true
> IMHO: nope -- this issue is 12 years old!
>
> MNG-7429 The classloader containing build extensions should be used
> throughout the build
> IMHO nope: (unless regression from some 3.8.x)
>
> MNG-7448 if we delete bin directory in apache-maven/src, we can not find
> because git has ignore it .
> IMHO nope: ???
>
> MNG-7439 Make fields of CliRequest protected
> IMHO nope
>
>
> So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
> out, forget it, no more fixes (unless some really serious regression is
> reported, but otherwise nada).
>
> # Maven 3.9.x
>
> IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
> ready to merge) as then Maven will get much much more goodness (not only
> 1.7.x locking, but also extensible checksums, smart checksums, provided
> checksums, DF and BF collector, ability for signature resolution, proper
> ignores for artifacts not needed checksums). To make smart checksums usable
> for maven, http transport is needed as well (PR as it is no go, it needs to
> make Wagon still remain default transport, will fix that). Or, we could
> make it as is, and then if anyone has issues or badly wants Wagon, there is
> a command line to make it so....
>
> So, IMHO, for 3.9.x
>
> - Port fixes that we decide to be done in 3.8.6 naturally
> - Use resolver 1.8.0 (wait for it, one remaining PR merge, released
> hopefully very soon)
> - Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
> default or not. Also this PR would get rid of shaded stuff as well.
>
> And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
> some serious regression falls in).
>
> # Maven 4
>
> Guillaume already did a huge amount of work that he probably needs help on,
> so help him to wrap up things....
>
>
>
> WDYT?
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-04-10 um 19:59 schrieb Hervé BOUTEMY:
> Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
>> Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
>>
>>>> I think that the truth is that versions less than 3.8.x are also EOL.
>>>
>>> no
>>> please read the EOL message we took a lot of discussion to define for
>>> Maven
> 3.0.x:
>>> "Maven 3.0 has now reached its end of life. New plugin releases will
>>> require
> Maven 3.1 or later."
>>>
>>> yes, the definition of what "EOL" and "supported" mean for a project like
>>> ours
> is not so easy: finding the right message is not easy
>>
>>
>> But I don't think that this is the full truth.
>> What we actually do is to compile against a specific Maven version, but
>> only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
>> and so it -- I don't and will not.
> 1. our CI tests quite a good number of situations: we don't expect manual test
> from every committer
> 2. even if we don't fully test every detailed situation, we defined our minimum
> required Maven version to show that we support these situation
> 3. if you go that route, please define what support means given our OSS nature
How can we support a version if we even don't have it on CI which tests?
This looks like deception, no? The first we ask when I plugin issue
arrives is to upgrade Maven, no?
I totally agree, that we only test 3.8.x+. Everything else is best effort.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
Maybe something like on Node's page
https://nodejs.org/en/about/releases/
S.
śr., 13 kwi 2022, 22:21 użytkownik Hervé BOUTEMY <he...@free.fr>
napisał:
> I near fully agree: I'd just replace "not maintained" with something like
> "stable"
>
> Le lundi 11 avril 2022, 18:44:31 CEST Manfred Moser a écrit :
> > I could not agree more. It is extremely important for users to understand
> > that we are NOT a commercial entity providing support. And contrary to
> > other open source products there is large, well known commercial entity
> > either.
> >
> > I also second all the other points from Tamas.
> >
> > Manfred
> >
> > Tamás Cservenák wrote on 2022-04-11 03:02 (GMT -07:00):
> > > Howdy,
> > >
> > > Personally, I'd NOT use the term "supported" at all, as it comes from
> the
> > > commercial realm (at least for me it sounds like it).
> > > We do not support anything :)
> >
> > ---------------------------------------------------------------------
> > 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: We need to lay down strategy
Posted by Hervé BOUTEMY <he...@free.fr>.
I near fully agree: I'd just replace "not maintained" with something like
"stable"
Le lundi 11 avril 2022, 18:44:31 CEST Manfred Moser a écrit :
> I could not agree more. It is extremely important for users to understand
> that we are NOT a commercial entity providing support. And contrary to
> other open source products there is large, well known commercial entity
> either.
>
> I also second all the other points from Tamas.
>
> Manfred
>
> Tamás Cservenák wrote on 2022-04-11 03:02 (GMT -07:00):
> > Howdy,
> >
> > Personally, I'd NOT use the term "supported" at all, as it comes from the
> > commercial realm (at least for me it sounds like it).
> > We do not support anything :)
>
> ---------------------------------------------------------------------
> 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: We need to lay down strategy
Posted by Tamás Cservenák <ta...@cservenak.net>.
Errata below:
So, if for some business reason you are forced to use any pre Java 8 for
> development, you have two options:
> - use the latest Maven and toolchains targeting old Java
> - use the same versions of tools that are from the era when that Java was
> latest. Accept that with non-evolved Java your Java toolbox cannot evolve
> either.
>
So, if for some business reason you are forced to CODE AGAINST pre Java 8
runtime platform , you have two options:
- use the latest Java and Maven and make use of toolchains targeting old
Java (same thing you probably do with your IDE as well)
- use the same versions of tools that are from the era when that Java was
latest. Accept that with non-evolved Java your Java toolbox cannot evolve
either.
T
Re: We need to lay down strategy
Posted by Jorge Solórzano <jo...@gmail.com>.
I fully agree, but all of this must be clearly defined on the web page.
Right now https://maven.apache.org/docs/history.html is not clear
about what is and what is not "maintained", and also many plugins
still "target" Maven 3.1.1 or 3.2.5, hopefully this proposal along
with the "Radical Fast Forward to 3.5.4"[1] will help to lay down the
strategy to use.
[1] https://cwiki.apache.org/confluence/display/MAVEN/Baseline+Upgrade+to+Maven+3.5.4
On Mon, Apr 11, 2022 at 12:02 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> Personally, I'd NOT use the term "supported" at all, as it comes from the
> commercial realm (at least for me it sounds like it).
> We do not support anything :)
>
> I'd use the word "maintained" instead. So, according to that:
> maven 3.8.x is "maintained ONLY for critical regressions"
> maven 3.9.x is coming next out, but more about it later.
> maven 4.x is round the corner, and is our main focus (or will be very soon).
> Anything else of Maven Core is unmaintained.
> Regarding plugins, the very first response we usually do on ML is "did you
> try the latest version?".
>
> But regarding core, Maven major versions 2.x and 3.x were "backward
> compatible", the heck, MANY builds today still use plugins having
> MAJOR version 2.x, implying they use Maven 2 API:
> - m-install-p (2.5.2 released in 2014),
> - m-deploy-p (2.8.2 released in 2014)
> - m-surefire-p (2.22.2 released in 2019)
> etc
>
> The Maven 2.x -> 3.x transition -- as example shows -- was made with a
> major goal set to "ease the transition",
> and it worked: Maven core was radically changed (container, resolver, etc),
> but surrounding 2.x Mojos kept working as expected.
>
> OTOH, exactly this "smooth transition" caused a lot of technical issues and
> debt, that needs to be addressed,
> and will be addressed in Maven 4.x, but this time it will not tackle only
> things "behind the curtain", but may
> be a bit more jolty for plugins as well, hence for end users. Probably will
> require a new 4.x line of plugins as well
> (as we tried to introduce a 3.x line of plugins telling they are "aligned"
> with maven 3.x).
>
> The maven-3.9.x branch is technically at a similar level as maven-3.8.x,
> but the exact intent is to up its Java level
> to Java 8, to make it able to "keep up" with dependencies surrounding it
> and pick up the latest features from them,
> like new resolver is, etc. The Maven 3.9.x will be "just" a new Maven 3.x
> release with great and new (already done
> elsewhere) features, but no major Maven feature itself. Once maven-3.9.x is
> out, maven-3.8.x becomes "not maintained",
> and 3.9.x is "maintained for regressions".
>
> For new features, we should really focus on Maven 4.x.
>
> IMHO, just like (hopefully) you do with your OS and IDE, keep it up to
> date, I see no reason why someone would
> not do the same for their development environment as well. Keep it up to
> date. Especially now with the "new" Java
> LTS programme, where Java 8 is really OLDEST LTS for many years, but
> current LTS Java is 17, and the next LTS
> is behind the corner as well (2023?).
>
> I fully understand developers stuck on Java 5 or 7 or anything pre 8, but
> they should understand us as well:
> - we have no commercial licenses for those things
> - hence, we cannot test against them, even if we would have access to
> those, we are OSS project, we have no resources to do that
> Nb: same happened in SCM project: commercial SCM systems were dropped, we
> cannot maintain something we cannot test.
>
> So, if for some business reason you are forced to use any pre Java 8 for
> development, you have two options:
> - use the latest Maven and toolchains targeting old Java
> - use the same versions of tools that are from the era when that Java was
> latest. Accept that with non-evolved Java your Java toolbox cannot evolve
> either.
>
> My 5 cents
> T
>
>
> On Mon, Apr 11, 2022 at 11:25 AM Jorge Solórzano <jo...@gmail.com> wrote:
>
> > Honestly, the first thing to clarify is, what it means supported/EOL
> > in Maven terms?. There is a lot of confusion of what it's supported
> > since it's expected that newer versions of Maven should be
> > "backward-compatible" with previous versions of Maven.
> >
> > If I have a project that was "initially" designed for Maven 3.1.1
> > (meaning that the pom works perfectly fine with that version) and then
> > I simply upgrade Maven to 3.8.x, the project should "just works"? or
> > there is a need to update the pom.xml/plugins, etc too?
> > And the reverse should be possible? if I have a project designed for
> > 3.8.x, should it work with Maven 3.2.5? At least I know that 3.6.x and
> > 3.8.x should be more or less "backward-compatible", but it's hard to
> > tell if others are.
> >
> > Second, supported means that it still receives updates or patches, and
> > gets released every now and then, this is not true at all, the last
> > version of Maven 3.1.x was 3.1.1 released on 2013-10-04, the other
> > name for "supported" of older versions is in "maintenance", that might
> > receive critical fixes, yet again this might never happen. In the same
> > line, Maven 3.1.x requires Java 5 which is essentially dead since a
> > very long time ago, "supporting" Maven 3.1.x is pretty much nonsense.
> > (Here I'm talking about Maven core).
> >
> > Even trying to "support" Maven 3.2.x (3.2.5 released on 2014-12-20) as
> > it requires Java 6 is impractical, as Java 6 was EOL 3 years ago (31
> > Dec 2018). In other words if a plugin "claims" to support Maven 3.1.1,
> > it should work with Java 5, in any other case it's just "partially"
> > compatible and having a table of compatibility is required as it's not
> > true that it "supports" Maven 3.1.1.
> >
> > So, it's hard to define what it means "supported" and "EOL" here, does
> > it mean that "plugins" are supported? in other words, that if a new
> > plugin is released it should work with Maven 3.1.0? (even if it's hard
> > to test on that combination), the CI matrix should test plugins with a
> > combo of Java 6, Java 7, Java 8, Java 11 and Java 17, multiplied by
> > Maven 3.1.1, Maven 3.2.5, Maven 3.3.9, 3.5.4, 3.6.3, and 3.8.5, which
> > I seriously doubt it happen.
> >
> > In the end, if my project was initially designed for Maven 3.1.1, I do
> > not expect that I (or many other users) will just update plugins
> > without also testing or updating to newer Maven versions too, so,
> > having plugins "supporting" such older versions of Maven is not
> > necessarily a good thing, it might make sense if the "supported"
> > definition is latest + 2 older versions (3.8.x, 3.6.3, 3.5.4), this if
> > we are speaking of plugins, as for Maven itself is still not clear to
> > me what it means "supported" as once a new versions is released
> > (3.8.x) the older one never get any update (3.6.x).
> >
> > And yet again, we enter into a new conflict with this definition, if
> > Maven 3.9.x requires Java 8 and a lot of plugins are also moving to
> > Java 8, then it effectively means that "older" versions will not be
> > supported by plugins (in the combination of Java 6 and 7).
> >
> > Welcome to the pandora box!
> >
> > On Mon, Apr 11, 2022 at 11:08 AM <he...@free.fr> wrote:
> > >
> > > you're focusing on Maven core only
> > > I'm talking about Maven = core + plugins
> > >
> > > and on Maven core, 3.9 and master are for new features, 3.8 is a
> > stabilisation branch only (bugfixes) = the intent of initial message from
> > Tamas
> > >
> > > older releases are stable: yes, we don't expect fixes because they are
> > considered stable
> > >
> > > does stable mean EOL?
> > >
> > > no, because it would mean that we only support unstable versions of
> > Maven core
> > >
> > > ----- Mail original -----
> > > De: "Slawomir Jaranowski" <s....@gmail.com>
> > > À: "Maven Developers List" <de...@maven.apache.org>
> > > Envoyé: Dimanche 10 Avril 2022 21:20:33
> > > Objet: Re: We need to lay down strategy
> > >
> > > our CI has running build for branches:
> > > - master
> > > - 3.9.x
> > > - 3.8.x
> > >
> > > It is only versions for which we can do changes, for others we simply
> > don't
> > > have running infrastructure, so the rest of the versions should be
> > > officially mentioned as EOL.
> > >
> > > To be clear we also should add information what kind of change will be
> > > accepted for specific version, like: 3.8.x, 3.9.x only critical
> > regression
> > > bugs as Tamás mentions
> > >
> > > niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
> > > napisał(a):
> > >
> > > > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > > > >
> > > > > >> I think that the truth is that versions less than 3.8.x are also
> > EOL.
> > > > > >
> > > > > > no
> > > > > > please read the EOL message we took a lot of discussion to define
> > for
> > > > > > Maven
> > > > 3.0.x:
> > > > > > "Maven 3.0 has now reached its end of life. New plugin releases
> > will
> > > > > > require
> > > > Maven 3.1 or later."
> > > > > >
> > > > > > yes, the definition of what "EOL" and "supported" mean for a
> > project
> > > > like
> > > > > > ours
> > > > is not so easy: finding the right message is not easy
> > > > >
> > > > >
> > > > > But I don't think that this is the full truth.
> > > > > What we actually do is to compile against a specific Maven version,
> > but
> > > > > only test latest. I don't expect that everyone tests with 3.1.x,
> > 3.2.x
> > > > > and so it -- I don't and will not.
> > > > 1. our CI tests quite a good number of situations: we don't expect
> > manual
> > > > test
> > > > from every committer
> > > > 2. even if we don't fully test every detailed situation, we defined our
> > > > minimum
> > > > required Maven version to show that we support these situation
> > > > 3. if you go that route, please define what support means given our OSS
> > > > nature
> > > >
> > > > let's be reasonable at every level
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Manfred Moser <ma...@simpligility.com>.
I could not agree more. It is extremely important for users to understand that we
are NOT a commercial entity providing support. And contrary to other open source
products there is large, well known commercial entity either.
I also second all the other points from Tamas.
Manfred
Tamás Cservenák wrote on 2022-04-11 03:02 (GMT -07:00):
> Howdy,
>
> Personally, I'd NOT use the term "supported" at all, as it comes from the
> commercial realm (at least for me it sounds like it).
> We do not support anything :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
Personally, I'd NOT use the term "supported" at all, as it comes from the
commercial realm (at least for me it sounds like it).
We do not support anything :)
I'd use the word "maintained" instead. So, according to that:
maven 3.8.x is "maintained ONLY for critical regressions"
maven 3.9.x is coming next out, but more about it later.
maven 4.x is round the corner, and is our main focus (or will be very soon).
Anything else of Maven Core is unmaintained.
Regarding plugins, the very first response we usually do on ML is "did you
try the latest version?".
But regarding core, Maven major versions 2.x and 3.x were "backward
compatible", the heck, MANY builds today still use plugins having
MAJOR version 2.x, implying they use Maven 2 API:
- m-install-p (2.5.2 released in 2014),
- m-deploy-p (2.8.2 released in 2014)
- m-surefire-p (2.22.2 released in 2019)
etc
The Maven 2.x -> 3.x transition -- as example shows -- was made with a
major goal set to "ease the transition",
and it worked: Maven core was radically changed (container, resolver, etc),
but surrounding 2.x Mojos kept working as expected.
OTOH, exactly this "smooth transition" caused a lot of technical issues and
debt, that needs to be addressed,
and will be addressed in Maven 4.x, but this time it will not tackle only
things "behind the curtain", but may
be a bit more jolty for plugins as well, hence for end users. Probably will
require a new 4.x line of plugins as well
(as we tried to introduce a 3.x line of plugins telling they are "aligned"
with maven 3.x).
The maven-3.9.x branch is technically at a similar level as maven-3.8.x,
but the exact intent is to up its Java level
to Java 8, to make it able to "keep up" with dependencies surrounding it
and pick up the latest features from them,
like new resolver is, etc. The Maven 3.9.x will be "just" a new Maven 3.x
release with great and new (already done
elsewhere) features, but no major Maven feature itself. Once maven-3.9.x is
out, maven-3.8.x becomes "not maintained",
and 3.9.x is "maintained for regressions".
For new features, we should really focus on Maven 4.x.
IMHO, just like (hopefully) you do with your OS and IDE, keep it up to
date, I see no reason why someone would
not do the same for their development environment as well. Keep it up to
date. Especially now with the "new" Java
LTS programme, where Java 8 is really OLDEST LTS for many years, but
current LTS Java is 17, and the next LTS
is behind the corner as well (2023?).
I fully understand developers stuck on Java 5 or 7 or anything pre 8, but
they should understand us as well:
- we have no commercial licenses for those things
- hence, we cannot test against them, even if we would have access to
those, we are OSS project, we have no resources to do that
Nb: same happened in SCM project: commercial SCM systems were dropped, we
cannot maintain something we cannot test.
So, if for some business reason you are forced to use any pre Java 8 for
development, you have two options:
- use the latest Maven and toolchains targeting old Java
- use the same versions of tools that are from the era when that Java was
latest. Accept that with non-evolved Java your Java toolbox cannot evolve
either.
My 5 cents
T
On Mon, Apr 11, 2022 at 11:25 AM Jorge Solórzano <jo...@gmail.com> wrote:
> Honestly, the first thing to clarify is, what it means supported/EOL
> in Maven terms?. There is a lot of confusion of what it's supported
> since it's expected that newer versions of Maven should be
> "backward-compatible" with previous versions of Maven.
>
> If I have a project that was "initially" designed for Maven 3.1.1
> (meaning that the pom works perfectly fine with that version) and then
> I simply upgrade Maven to 3.8.x, the project should "just works"? or
> there is a need to update the pom.xml/plugins, etc too?
> And the reverse should be possible? if I have a project designed for
> 3.8.x, should it work with Maven 3.2.5? At least I know that 3.6.x and
> 3.8.x should be more or less "backward-compatible", but it's hard to
> tell if others are.
>
> Second, supported means that it still receives updates or patches, and
> gets released every now and then, this is not true at all, the last
> version of Maven 3.1.x was 3.1.1 released on 2013-10-04, the other
> name for "supported" of older versions is in "maintenance", that might
> receive critical fixes, yet again this might never happen. In the same
> line, Maven 3.1.x requires Java 5 which is essentially dead since a
> very long time ago, "supporting" Maven 3.1.x is pretty much nonsense.
> (Here I'm talking about Maven core).
>
> Even trying to "support" Maven 3.2.x (3.2.5 released on 2014-12-20) as
> it requires Java 6 is impractical, as Java 6 was EOL 3 years ago (31
> Dec 2018). In other words if a plugin "claims" to support Maven 3.1.1,
> it should work with Java 5, in any other case it's just "partially"
> compatible and having a table of compatibility is required as it's not
> true that it "supports" Maven 3.1.1.
>
> So, it's hard to define what it means "supported" and "EOL" here, does
> it mean that "plugins" are supported? in other words, that if a new
> plugin is released it should work with Maven 3.1.0? (even if it's hard
> to test on that combination), the CI matrix should test plugins with a
> combo of Java 6, Java 7, Java 8, Java 11 and Java 17, multiplied by
> Maven 3.1.1, Maven 3.2.5, Maven 3.3.9, 3.5.4, 3.6.3, and 3.8.5, which
> I seriously doubt it happen.
>
> In the end, if my project was initially designed for Maven 3.1.1, I do
> not expect that I (or many other users) will just update plugins
> without also testing or updating to newer Maven versions too, so,
> having plugins "supporting" such older versions of Maven is not
> necessarily a good thing, it might make sense if the "supported"
> definition is latest + 2 older versions (3.8.x, 3.6.3, 3.5.4), this if
> we are speaking of plugins, as for Maven itself is still not clear to
> me what it means "supported" as once a new versions is released
> (3.8.x) the older one never get any update (3.6.x).
>
> And yet again, we enter into a new conflict with this definition, if
> Maven 3.9.x requires Java 8 and a lot of plugins are also moving to
> Java 8, then it effectively means that "older" versions will not be
> supported by plugins (in the combination of Java 6 and 7).
>
> Welcome to the pandora box!
>
> On Mon, Apr 11, 2022 at 11:08 AM <he...@free.fr> wrote:
> >
> > you're focusing on Maven core only
> > I'm talking about Maven = core + plugins
> >
> > and on Maven core, 3.9 and master are for new features, 3.8 is a
> stabilisation branch only (bugfixes) = the intent of initial message from
> Tamas
> >
> > older releases are stable: yes, we don't expect fixes because they are
> considered stable
> >
> > does stable mean EOL?
> >
> > no, because it would mean that we only support unstable versions of
> Maven core
> >
> > ----- Mail original -----
> > De: "Slawomir Jaranowski" <s....@gmail.com>
> > À: "Maven Developers List" <de...@maven.apache.org>
> > Envoyé: Dimanche 10 Avril 2022 21:20:33
> > Objet: Re: We need to lay down strategy
> >
> > our CI has running build for branches:
> > - master
> > - 3.9.x
> > - 3.8.x
> >
> > It is only versions for which we can do changes, for others we simply
> don't
> > have running infrastructure, so the rest of the versions should be
> > officially mentioned as EOL.
> >
> > To be clear we also should add information what kind of change will be
> > accepted for specific version, like: 3.8.x, 3.9.x only critical
> regression
> > bugs as Tamás mentions
> >
> > niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
> > napisał(a):
> >
> > > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > > >
> > > > >> I think that the truth is that versions less than 3.8.x are also
> EOL.
> > > > >
> > > > > no
> > > > > please read the EOL message we took a lot of discussion to define
> for
> > > > > Maven
> > > 3.0.x:
> > > > > "Maven 3.0 has now reached its end of life. New plugin releases
> will
> > > > > require
> > > Maven 3.1 or later."
> > > > >
> > > > > yes, the definition of what "EOL" and "supported" mean for a
> project
> > > like
> > > > > ours
> > > is not so easy: finding the right message is not easy
> > > >
> > > >
> > > > But I don't think that this is the full truth.
> > > > What we actually do is to compile against a specific Maven version,
> but
> > > > only test latest. I don't expect that everyone tests with 3.1.x,
> 3.2.x
> > > > and so it -- I don't and will not.
> > > 1. our CI tests quite a good number of situations: we don't expect
> manual
> > > test
> > > from every committer
> > > 2. even if we don't fully test every detailed situation, we defined our
> > > minimum
> > > required Maven version to show that we support these situation
> > > 3. if you go that route, please define what support means given our OSS
> > > nature
> > >
> > > let's be reasonable at every level
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > Sławomir Jaranowski
> >
> > ---------------------------------------------------------------------
> > 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: We need to lay down strategy
Posted by Jorge Solórzano <jo...@gmail.com>.
Honestly, the first thing to clarify is, what it means supported/EOL
in Maven terms?. There is a lot of confusion of what it's supported
since it's expected that newer versions of Maven should be
"backward-compatible" with previous versions of Maven.
If I have a project that was "initially" designed for Maven 3.1.1
(meaning that the pom works perfectly fine with that version) and then
I simply upgrade Maven to 3.8.x, the project should "just works"? or
there is a need to update the pom.xml/plugins, etc too?
And the reverse should be possible? if I have a project designed for
3.8.x, should it work with Maven 3.2.5? At least I know that 3.6.x and
3.8.x should be more or less "backward-compatible", but it's hard to
tell if others are.
Second, supported means that it still receives updates or patches, and
gets released every now and then, this is not true at all, the last
version of Maven 3.1.x was 3.1.1 released on 2013-10-04, the other
name for "supported" of older versions is in "maintenance", that might
receive critical fixes, yet again this might never happen. In the same
line, Maven 3.1.x requires Java 5 which is essentially dead since a
very long time ago, "supporting" Maven 3.1.x is pretty much nonsense.
(Here I'm talking about Maven core).
Even trying to "support" Maven 3.2.x (3.2.5 released on 2014-12-20) as
it requires Java 6 is impractical, as Java 6 was EOL 3 years ago (31
Dec 2018). In other words if a plugin "claims" to support Maven 3.1.1,
it should work with Java 5, in any other case it's just "partially"
compatible and having a table of compatibility is required as it's not
true that it "supports" Maven 3.1.1.
So, it's hard to define what it means "supported" and "EOL" here, does
it mean that "plugins" are supported? in other words, that if a new
plugin is released it should work with Maven 3.1.0? (even if it's hard
to test on that combination), the CI matrix should test plugins with a
combo of Java 6, Java 7, Java 8, Java 11 and Java 17, multiplied by
Maven 3.1.1, Maven 3.2.5, Maven 3.3.9, 3.5.4, 3.6.3, and 3.8.5, which
I seriously doubt it happen.
In the end, if my project was initially designed for Maven 3.1.1, I do
not expect that I (or many other users) will just update plugins
without also testing or updating to newer Maven versions too, so,
having plugins "supporting" such older versions of Maven is not
necessarily a good thing, it might make sense if the "supported"
definition is latest + 2 older versions (3.8.x, 3.6.3, 3.5.4), this if
we are speaking of plugins, as for Maven itself is still not clear to
me what it means "supported" as once a new versions is released
(3.8.x) the older one never get any update (3.6.x).
And yet again, we enter into a new conflict with this definition, if
Maven 3.9.x requires Java 8 and a lot of plugins are also moving to
Java 8, then it effectively means that "older" versions will not be
supported by plugins (in the combination of Java 6 and 7).
Welcome to the pandora box!
On Mon, Apr 11, 2022 at 11:08 AM <he...@free.fr> wrote:
>
> you're focusing on Maven core only
> I'm talking about Maven = core + plugins
>
> and on Maven core, 3.9 and master are for new features, 3.8 is a stabilisation branch only (bugfixes) = the intent of initial message from Tamas
>
> older releases are stable: yes, we don't expect fixes because they are considered stable
>
> does stable mean EOL?
>
> no, because it would mean that we only support unstable versions of Maven core
>
> ----- Mail original -----
> De: "Slawomir Jaranowski" <s....@gmail.com>
> À: "Maven Developers List" <de...@maven.apache.org>
> Envoyé: Dimanche 10 Avril 2022 21:20:33
> Objet: Re: We need to lay down strategy
>
> our CI has running build for branches:
> - master
> - 3.9.x
> - 3.8.x
>
> It is only versions for which we can do changes, for others we simply don't
> have running infrastructure, so the rest of the versions should be
> officially mentioned as EOL.
>
> To be clear we also should add information what kind of change will be
> accepted for specific version, like: 3.8.x, 3.9.x only critical regression
> bugs as Tamás mentions
>
> niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
> napisał(a):
>
> > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > >
> > > >> I think that the truth is that versions less than 3.8.x are also EOL.
> > > >
> > > > no
> > > > please read the EOL message we took a lot of discussion to define for
> > > > Maven
> > 3.0.x:
> > > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > > require
> > Maven 3.1 or later."
> > > >
> > > > yes, the definition of what "EOL" and "supported" mean for a project
> > like
> > > > ours
> > is not so easy: finding the right message is not easy
> > >
> > >
> > > But I don't think that this is the full truth.
> > > What we actually do is to compile against a specific Maven version, but
> > > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > > and so it -- I don't and will not.
> > 1. our CI tests quite a good number of situations: we don't expect manual
> > test
> > from every committer
> > 2. even if we don't fully test every detailed situation, we defined our
> > minimum
> > required Maven version to show that we support these situation
> > 3. if you go that route, please define what support means given our OSS
> > nature
> >
> > let's be reasonable at every level
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>
> ---------------------------------------------------------------------
> 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: We need to lay down strategy
Posted by he...@free.fr.
you're focusing on Maven core only
I'm talking about Maven = core + plugins
and on Maven core, 3.9 and master are for new features, 3.8 is a stabilisation branch only (bugfixes) = the intent of initial message from Tamas
older releases are stable: yes, we don't expect fixes because they are considered stable
does stable mean EOL?
no, because it would mean that we only support unstable versions of Maven core
----- Mail original -----
De: "Slawomir Jaranowski" <s....@gmail.com>
À: "Maven Developers List" <de...@maven.apache.org>
Envoyé: Dimanche 10 Avril 2022 21:20:33
Objet: Re: We need to lay down strategy
our CI has running build for branches:
- master
- 3.9.x
- 3.8.x
It is only versions for which we can do changes, for others we simply don't
have running infrastructure, so the rest of the versions should be
officially mentioned as EOL.
To be clear we also should add information what kind of change will be
accepted for specific version, like: 3.8.x, 3.9.x only critical regression
bugs as Tamás mentions
niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
napisał(a):
> Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> >
> > >> I think that the truth is that versions less than 3.8.x are also EOL.
> > >
> > > no
> > > please read the EOL message we took a lot of discussion to define for
> > > Maven
> 3.0.x:
> > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > require
> Maven 3.1 or later."
> > >
> > > yes, the definition of what "EOL" and "supported" mean for a project
> like
> > > ours
> is not so easy: finding the right message is not easy
> >
> >
> > But I don't think that this is the full truth.
> > What we actually do is to compile against a specific Maven version, but
> > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > and so it -- I don't and will not.
> 1. our CI tests quite a good number of situations: we don't expect manual
> test
> from every committer
> 2. even if we don't fully test every detailed situation, we defined our
> minimum
> required Maven version to show that we support these situation
> 3. if you go that route, please define what support means given our OSS
> nature
>
> let's be reasonable at every level
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sławomir Jaranowski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Xeno Amess <xe...@gmail.com>.
So..If I wanna make some refinements, I shall put them onto 4.0, means
master, right?
Slawomir Jaranowski <s....@gmail.com> 于2022年4月11日周一 03:20写道：
> our CI has running build for branches:
> - master
> - 3.9.x
> - 3.8.x
>
> It is only versions for which we can do changes, for others we simply don't
> have running infrastructure, so the rest of the versions should be
> officially mentioned as EOL.
>
> To be clear we also should add information what kind of change will be
> accepted for specific version, like: 3.8.x, 3.9.x only critical regression
> bugs as Tamás mentions
>
> niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
> napisał(a):
>
> > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > >
> > > >> I think that the truth is that versions less than 3.8.x are also
> EOL.
> > > >
> > > > no
> > > > please read the EOL message we took a lot of discussion to define for
> > > > Maven
> > 3.0.x:
> > > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > > require
> > Maven 3.1 or later."
> > > >
> > > > yes, the definition of what "EOL" and "supported" mean for a project
> > like
> > > > ours
> > is not so easy: finding the right message is not easy
> > >
> > >
> > > But I don't think that this is the full truth.
> > > What we actually do is to compile against a specific Maven version, but
> > > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > > and so it -- I don't and will not.
> > 1. our CI tests quite a good number of situations: we don't expect manual
> > test
> > from every committer
> > 2. even if we don't fully test every detailed situation, we defined our
> > minimum
> > required Maven version to show that we support these situation
> > 3. if you go that route, please define what support means given our OSS
> > nature
> >
> > let's be reasonable at every level
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>
Re: We need to lay down strategy
Posted by Slawomir Jaranowski <s....@gmail.com>.
our CI has running build for branches:
- master
- 3.9.x
- 3.8.x
It is only versions for which we can do changes, for others we simply don't
have running infrastructure, so the rest of the versions should be
officially mentioned as EOL.
To be clear we also should add information what kind of change will be
accepted for specific version, like: 3.8.x, 3.9.x only critical regression
bugs as Tamás mentions
niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY <he...@free.fr>
napisał(a):
> Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> >
> > >> I think that the truth is that versions less than 3.8.x are also EOL.
> > >
> > > no
> > > please read the EOL message we took a lot of discussion to define for
> > > Maven
> 3.0.x:
> > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > require
> Maven 3.1 or later."
> > >
> > > yes, the definition of what "EOL" and "supported" mean for a project
> like
> > > ours
> is not so easy: finding the right message is not easy
> >
> >
> > But I don't think that this is the full truth.
> > What we actually do is to compile against a specific Maven version, but
> > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > and so it -- I don't and will not.
> 1. our CI tests quite a good number of situations: we don't expect manual
> test
> from every committer
> 2. even if we don't fully test every detailed situation, we defined our
> minimum
> required Maven version to show that we support these situation
> 3. if you go that route, please define what support means given our OSS
> nature
>
> let's be reasonable at every level
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sławomir Jaranowski
Re: We need to lay down strategy
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
>
> >> I think that the truth is that versions less than 3.8.x are also EOL.
> >
> > no
> > please read the EOL message we took a lot of discussion to define for
> > Maven
3.0.x:
> > "Maven 3.0 has now reached its end of life. New plugin releases will
> > require
Maven 3.1 or later."
> >
> > yes, the definition of what "EOL" and "supported" mean for a project like
> > ours
is not so easy: finding the right message is not easy
>
>
> But I don't think that this is the full truth.
> What we actually do is to compile against a specific Maven version, but
> only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> and so it -- I don't and will not.
1. our CI tests quite a good number of situations: we don't expect manual test
from every committer
2. even if we don't fully test every detailed situation, we defined our minimum
required Maven version to show that we support these situation
3. if you go that route, please define what support means given our OSS nature
let's be reasonable at every level
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
>> I think that the truth is that versions less than 3.8.x are also EOL.
> no
> please read the EOL message we took a lot of discussion to define for Maven
> 3.0.x:
> "Maven 3.0 has now reached its end of life. New plugin releases will require
> Maven 3.1 or later."
>
> yes, the definition of what "EOL" and "supported" mean for a project like ours
> is not so easy: finding the right message is not easy
But I don't think that this is the full truth.
What we actually do is to compile against a specific Maven version, but
only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
and so it -- I don't and will not.
Re: We need to lay down strategy
Posted by Hervé BOUTEMY <he...@free.fr>.
> I think that the truth is that versions less than 3.8.x are also EOL.
no
please read the EOL message we took a lot of discussion to define for Maven
3.0.x:
"Maven 3.0 has now reached its end of life. New plugin releases will require
Maven 3.1 or later."
yes, the definition of what "EOL" and "supported" mean for a project like ours
is not so easy: finding the right message is not easy
Regards,
Hervé
Le samedi 9 avril 2022, 15:04:52 CEST Slawomir Jaranowski a écrit :
> Hi,
>
> Greate plan.
>
> According to that we want don't support old version we should update
> release history page [1]
> We should clear communicate to user what is supported.
>
> Now version less than 3.0.x are officially marked for EOL
>
> I think that the truth is that versions less than 3.8.x are also EOL.
>
> [1] https://maven.apache.org/docs/history.html
>
> czw., 7 kwi 2022 o 10:18 Tamás Cservenák <ta...@cservenak.net> napisał(a):
> > ... to not dissipate and reduce our (effort) losses :)
> >
> > Howdy,
> >
> > In short, I think we can agree on this sentence:
> > "we need to get rid of maven 3.8.x as fast as possible, release maven
> > 3.9.x
> > and once out, keep it on regression fixes until maven 4 is ready".
> >
> > # Get rid of Maven 3.8.x
> >
> > Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
> > must:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20res
> > olution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%2
> > 0priority%20DESC%2C%20updated%20DESC
> >
> > There are some other issues "affects 3.8.5" but I don't see them as
> > blockers (but please argue if you disagree):
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20res
> > olution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%2
> > 0BY%20priority%20DESC%2C%20updated%20DESC
> >
> > Out of them:
> >
> > MNG-7432 [REGRESSION] Dependencies from profile not picked up via
> > -P<profileName>
> > Must be fixed (PR merge pending)
> >
> > MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
> > can lock each other
> > Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
> > Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
> > this looks too vague to me, as Guillaume PR for sure cannot deadlock two
> > JVMs.... (it uses in-JVM locks).
> >
> > MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
> > Anyone? Unsure what is happening here, also how are these "new classes in
> > 3.8.5"?
> >
> > MNG-7441 Update Version of Logback to Address CVE-2021-42550
> > We should do this, as we plan to keep 3.8.x on the shelf for a while.
> > Hence, we will get more and more reports like these from end users. Let's
> > cut it from the root.
> >
> > MNG-7438 add execution id to "Configuring mojo xxx with basic
> > configurator"
> > debug message
> > IMHO: nope
> >
> > MNG-4917 Profile not active even though it has activeByDefault set to true
> > IMHO: nope -- this issue is 12 years old!
> >
> > MNG-7429 The classloader containing build extensions should be used
> > throughout the build
> > IMHO nope: (unless regression from some 3.8.x)
> >
> > MNG-7448 if we delete bin directory in apache-maven/src, we can not find
> > because git has ignore it .
> > IMHO nope: ???
> >
> > MNG-7439 Make fields of CliRequest protected
> > IMHO nope
> >
> >
> > So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
> > out, forget it, no more fixes (unless some really serious regression is
> > reported, but otherwise nada).
> >
> > # Maven 3.9.x
> >
> > IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
> > ready to merge) as then Maven will get much much more goodness (not only
> > 1.7.x locking, but also extensible checksums, smart checksums, provided
> > checksums, DF and BF collector, ability for signature resolution, proper
> > ignores for artifacts not needed checksums). To make smart checksums
> > usable
> > for maven, http transport is needed as well (PR as it is no go, it needs
> > to
> > make Wagon still remain default transport, will fix that). Or, we could
> > make it as is, and then if anyone has issues or badly wants Wagon, there
> > is
> > a command line to make it so....
> >
> > So, IMHO, for 3.9.x
> >
> > - Port fixes that we decide to be done in 3.8.6 naturally
> > - Use resolver 1.8.0 (wait for it, one remaining PR merge, released
> > hopefully very soon)
> > - Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
> > default or not. Also this PR would get rid of shaded stuff as well.
> >
> > And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
> > some serious regression falls in).
> >
> > # Maven 4
> >
> > Guillaume already did a huge amount of work that he probably needs help
> > on,
> > so help him to wrap up things....
> >
> >
> >
> > WDYT?
> > T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We need to lay down strategy
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi,
Greate plan.
According to that we want don't support old version we should update
release history page [1]
We should clear communicate to user what is supported.
Now version less than 3.0.x are officially marked for EOL
I think that the truth is that versions less than 3.8.x are also EOL.
[1] https://maven.apache.org/docs/history.html
czw., 7 kwi 2022 o 10:18 Tamás Cservenák <ta...@cservenak.net> napisał(a):
> ... to not dissipate and reduce our (effort) losses :)
>
> Howdy,
>
> In short, I think we can agree on this sentence:
> "we need to get rid of maven 3.8.x as fast as possible, release maven 3.9.x
> and once out, keep it on regression fixes until maven 4 is ready".
>
> # Get rid of Maven 3.8.x
>
> Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
> must:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> There are some other issues "affects 3.8.5" but I don't see them as
> blockers (but please argue if you disagree):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Out of them:
>
> MNG-7432 [REGRESSION] Dependencies from profile not picked up via
> -P<profileName>
> Must be fixed (PR merge pending)
>
> MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
> can lock each other
> Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
> Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
> this looks too vague to me, as Guillaume PR for sure cannot deadlock two
> JVMs.... (it uses in-JVM locks).
>
> MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
> Anyone? Unsure what is happening here, also how are these "new classes in
> 3.8.5"?
>
> MNG-7441 Update Version of Logback to Address CVE-2021-42550
> We should do this, as we plan to keep 3.8.x on the shelf for a while.
> Hence, we will get more and more reports like these from end users. Let's
> cut it from the root.
>
> MNG-7438 add execution id to "Configuring mojo xxx with basic configurator"
> debug message
> IMHO: nope
>
> MNG-4917 Profile not active even though it has activeByDefault set to true
> IMHO: nope -- this issue is 12 years old!
>
> MNG-7429 The classloader containing build extensions should be used
> throughout the build
> IMHO nope: (unless regression from some 3.8.x)
>
> MNG-7448 if we delete bin directory in apache-maven/src, we can not find
> because git has ignore it .
> IMHO nope: ???
>
> MNG-7439 Make fields of CliRequest protected
> IMHO nope
>
>
> So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
> out, forget it, no more fixes (unless some really serious regression is
> reported, but otherwise nada).
>
> # Maven 3.9.x
>
> IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
> ready to merge) as then Maven will get much much more goodness (not only
> 1.7.x locking, but also extensible checksums, smart checksums, provided
> checksums, DF and BF collector, ability for signature resolution, proper
> ignores for artifacts not needed checksums). To make smart checksums usable
> for maven, http transport is needed as well (PR as it is no go, it needs to
> make Wagon still remain default transport, will fix that). Or, we could
> make it as is, and then if anyone has issues or badly wants Wagon, there is
> a command line to make it so....
>
> So, IMHO, for 3.9.x
>
> - Port fixes that we decide to be done in 3.8.6 naturally
> - Use resolver 1.8.0 (wait for it, one remaining PR merge, released
> hopefully very soon)
> - Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
> default or not. Also this PR would get rid of shaded stuff as well.
>
> And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
> some serious regression falls in).
>
> # Maven 4
>
> Guillaume already did a huge amount of work that he probably needs help on,
> so help him to wrap up things....
>
>
>
> WDYT?
> T
>
--
Sławomir Jaranowski
Re: We need to lay down strategy
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
Just a short status update.
So, Maven bugfix 3.8.6 has all selected issues fixed, add more if you want
(remember, only regressions and super-trivial a'la logback):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.8.6
Maven 3.9.0 has 2 new tasks added by me (resolver 1.8.0 is one of them) and
some are open/in progress:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.0
Resolver 1.8.0 release seems imminent:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.8.0
Have fun
T
On Thu, Apr 7, 2022 at 10:17 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> ... to not dissipate and reduce our (effort) losses :)
>
> Howdy,
>
> In short, I think we can agree on this sentence:
> "we need to get rid of maven 3.8.x as fast as possible, release maven
> 3.9.x and once out, keep it on regression fixes until maven 4 is ready".
>
> # Get rid of Maven 3.8.x
>
> Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
> must:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> There are some other issues "affects 3.8.5" but I don't see them as
> blockers (but please argue if you disagree):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Out of them:
>
> MNG-7432 [REGRESSION] Dependencies from profile not picked up via
> -P<profileName>
> Must be fixed (PR merge pending)
>
> MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
> can lock each other
> Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
> Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
> this looks too vague to me, as Guillaume PR for sure cannot deadlock two
> JVMs.... (it uses in-JVM locks).
>
> MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
> Anyone? Unsure what is happening here, also how are these "new classes in
> 3.8.5"?
>
> MNG-7441 Update Version of Logback to Address CVE-2021-42550
> We should do this, as we plan to keep 3.8.x on the shelf for a while.
> Hence, we will get more and more reports like these from end users. Let's
> cut it from the root.
>
> MNG-7438 add execution id to "Configuring mojo xxx with basic
> configurator" debug message
> IMHO: nope
>
> MNG-4917 Profile not active even though it has activeByDefault set to true
> IMHO: nope -- this issue is 12 years old!
>
> MNG-7429 The classloader containing build extensions should be used
> throughout the build
> IMHO nope: (unless regression from some 3.8.x)
>
> MNG-7448 if we delete bin directory in apache-maven/src, we can not find
> because git has ignore it .
> IMHO nope: ???
>
> MNG-7439 Make fields of CliRequest protected
> IMHO nope
>
>
> So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
> out, forget it, no more fixes (unless some really serious regression is
> reported, but otherwise nada).
>
> # Maven 3.9.x
>
> IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
> ready to merge) as then Maven will get much much more goodness (not only
> 1.7.x locking, but also extensible checksums, smart checksums, provided
> checksums, DF and BF collector, ability for signature resolution, proper
> ignores for artifacts not needed checksums). To make smart checksums usable
> for maven, http transport is needed as well (PR as it is no go, it needs to
> make Wagon still remain default transport, will fix that). Or, we could
> make it as is, and then if anyone has issues or badly wants Wagon, there is
> a command line to make it so....
>
> So, IMHO, for 3.9.x
>
> - Port fixes that we decide to be done in 3.8.6 naturally
> - Use resolver 1.8.0 (wait for it, one remaining PR merge, released
> hopefully very soon)
> - Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
> default or not. Also this PR would get rid of shaded stuff as well.
>
> And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
> some serious regression falls in).
>
> # Maven 4
>
> Guillaume already did a huge amount of work that he probably needs help
> on, so help him to wrap up things....
>
>
>
> WDYT?
> T
>
Re: We need to lay down strategy
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-04-14 um 15:35 schrieb Christoph Läubrich:
> Is there any plan when to release maven 3.8.6?
It depends whether or when all necessary tickets have been addressed. If
so, I'd go with a release something around 2022-05-08.
M
Re: We need to lay down strategy
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
Is there any plan when to release maven 3.8.6?
Am 07.04.22 um 10:17 schrieb Tamás Cservenák:
> ... to not dissipate and reduce our (effort) losses :)
>
> Howdy,
>
> In short, I think we can agree on this sentence:
> "we need to get rid of maven 3.8.x as fast as possible, release maven 3.9.x
> and once out, keep it on regression fixes until maven 4 is ready".
>
> # Get rid of Maven 3.8.x
>
> Hence, I think we MUST do 3.8.6, as there is one regression that it IMHO a
> must:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%203.8.6%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> There are some other issues "affects 3.8.5" but I don't see them as
> blockers (but please argue if you disagree):
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.8.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Out of them:
>
> MNG-7432 [REGRESSION] Dependencies from profile not picked up via
> -P<profileName>
> Must be fixed (PR merge pending)
>
> MNG-7433 [REGRESSION] Multiple maven instances working on same source tree
> can lock each other
> Fluke IMHO, but as Dan is an old Maven biker, I think he uses Takari
> Lifecycle plus maybe even Takari Local Repo extension, unsure. Definitely
> this looks too vague to me, as Guillaume PR for sure cannot deadlock two
> JVMs.... (it uses in-JVM locks).
>
> MNG-7449 [REGRESSION] StringVisitorModelInterpolator NullPointerException
> Anyone? Unsure what is happening here, also how are these "new classes in
> 3.8.5"?
>
> MNG-7441 Update Version of Logback to Address CVE-2021-42550
> We should do this, as we plan to keep 3.8.x on the shelf for a while.
> Hence, we will get more and more reports like these from end users. Let's
> cut it from the root.
>
> MNG-7438 add execution id to "Configuring mojo xxx with basic configurator"
> debug message
> IMHO: nope
>
> MNG-4917 Profile not active even though it has activeByDefault set to true
> IMHO: nope -- this issue is 12 years old!
>
> MNG-7429 The classloader containing build extensions should be used
> throughout the build
> IMHO nope: (unless regression from some 3.8.x)
>
> MNG-7448 if we delete bin directory in apache-maven/src, we can not find
> because git has ignore it .
> IMHO nope: ???
>
> MNG-7439 Make fields of CliRequest protected
> IMHO nope
>
>
> So, let's agree on what to fix for 3.8.6 and push it out... and once 3.8.6
> out, forget it, no more fixes (unless some really serious regression is
> reported, but otherwise nada).
>
> # Maven 3.9.x
>
> IMHO, Maven 3.9.0 should wait for resolver 1.8.x (has one remaining PR
> ready to merge) as then Maven will get much much more goodness (not only
> 1.7.x locking, but also extensible checksums, smart checksums, provided
> checksums, DF and BF collector, ability for signature resolution, proper
> ignores for artifacts not needed checksums). To make smart checksums usable
> for maven, http transport is needed as well (PR as it is no go, it needs to
> make Wagon still remain default transport, will fix that). Or, we could
> make it as is, and then if anyone has issues or badly wants Wagon, there is
> a command line to make it so....
>
> So, IMHO, for 3.9.x
>
> - Port fixes that we decide to be done in 3.8.6 naturally
> - Use resolver 1.8.0 (wait for it, one remaining PR merge, released
> hopefully very soon)
> - Apply https://github.com/apache/maven/pull/635 and decide: keep Wagon
> default or not. Also this PR would get rid of shaded stuff as well.
>
> And that's pretty much it. Keep 3.9.x on regression fixes only (so only if
> some serious regression falls in).
>
> # Maven 4
>
> Guillaume already did a huge amount of work that he probably needs help on,
> so help him to wrap up things....
>
>
>
> WDYT?
> T
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org