> 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
