Sure, and to repeat: Am fine with whatever Maven users install on their machines (managed or not), if they install Maven 3.1.0 in 2023, am fine with that. Naturally, when they will try to report an issue, our very first reaction will be "please upgrade".
Plugins (or even Resolver) are NOT "bound" to latest Maven, you can use them in whatever version of Maven (well, currently ASF Maven Core plugins target 3.2.5 as prerequisite) as *plugin* or as *dependency*. But *building* them out of source, that is something completely different. Then you are not "using" the resolver, you are "building" the resolver, so don't mix the two. During *building* it, this "robustness" principle, that is otherwise welcome and present (as *using* plugins or *depending* on resolver with Maven 3.2.5) IMHO is _unwanted_: we define the matrix of CI jobs by OS, Java version and Maven version, so should we now broaden the matrix to java8u110, java8u250 and java8u300 (since somewhere between these changes regarding keystore)? So again, this release of Resolver 1.9.9, once integrated into Maven 3.9.2 and released, will happily hum along on your fairly up to date MacBook with Java 8u172. Just don't run the Resolver UTs :) T On Thu, Apr 27, 2023 at 1:15 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > On Thu, Apr 27, 2023 at 6:52 AM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > Thanks Elliotte! > > > > But allow me a bit of a rant here: > > - You explicitly reported "on my personal and slightly more up to date > > MacBook [...] [the test fails, hence am -1 on release]". > > - Then it turns out, you use Maven 3.5.0 (from 2018, unmaintained). > > 3.5.0 was the corp Macbook. My personal MacBook is 3.8.7 atm. > > > - Then it turns out, you use Java 8u172 (from 2018, obviously outdated as > > current Java 8 is u300-ish). > > > > All this caused a huge pollution to the voting thread. > > > > Personally, I don't care what downstream developers use (outdated Maven > > and/or Java and even OS) to build their stuff, > > but "at the source", where we produce Maven and related libraries for > > downstream consumption, > > we should be REALLY up to date. This is in OUR favor, just to make sure > all > > the known issues from our > > tools can be excluded (or if new issues found, easier to find them), as > > much as possible. > > I think that's likely to produce far more weird, hard-to-debug > breakages of Maven on end users' machines. IMHO we are already far too > aggressive in what we consider supported. The enterprise and big tech > world simply does not upgrade that fast. For instance, 3.5.0 is what I > had on my day job machine because that's what the package manager > installs in 2023, not because it's the version I picked. > > There is a clear distinction between Maven itself and the plugins and > libraries pulled in via a pom.xml. Maven is a tool installed on end > users machines and is years out of date in many cases. Libraries > published for consumption by builds through declarations in the > pom.xml, and this includes plugins, should not be tightly coupled to > the versions of tools installed on end user systems such as mvn and > the JDK. It's the robustness principle in action, be conservative in > what you send, be liberal in what you accept. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >