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: [email protected] For additional commands, e-mail: [email protected]
