We nearly never backport fixes. Support just means that there is a chance it still works.. realistically we only support latest release..
Manfred Tibor Digana wrote on 2020-04-16 13:30 (GMT -07:00): > I want to ask a question regarding the maintenance of old minor > versions because i've started missing the right meaning of what > deprecation of Maven (not plugins) means. > Due to now we are at Maven 3.6.3 we support the bugfixing of 3.6.x > family. But AFAIK we won't suppor bugfixing of 3.5 families and > earlier. Would it mean that all versions prior to 3.6 could be > deprecated so? If they are not deprecated then the users may expect > bugfixing. > > On Thu, Apr 16, 2020 at 9:06 PM Robert Scholte <rfscho...@apache.org> wrote: >> >> The answer is 3.1.0. It is way more easier to say "plugins are Maven 3.1 or >> 3.1.x compatible". >> The APIs are the same, there should be no impact. >> So compile with 3.1.0 dependencies, run on Jenkins with 3.1.1 (as being the >> last 3.1.x release, like we do with all 3.x.latest) >> >> We had the same discussion when talking about 3.0 or 3.0.5, with the result: >> plugins should be Maven 3 compatible. >> >> Also be careful with the wording: >> we're not deprecating Maven 3.0.x, but plugins will require Maven 3.1 (or >> drop >> Maven 3.0 SUPPORT for plugins) >> A title like this is very misleading. >> >> Robert >> On 16-4-2020 13:01:39, Sylwester Lachiewicz <slachiew...@gmail.com> wrote: >> So next quick question - should be 3.1.0 or 3.1.1 - last and recommend >> version for Java 5? >> >> Sylwester >> >> czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana >> napisał: >> >> > I agree with Herve to start with deprecating 3.0.x. >> > And what sounds nice to me is producing the plugins with 3.1 as >> > minimum and clearing the old code and tests for 3.0.x. >> > This sounds like a plan for the community. >> > >> > On Thu, Apr 16, 2020 at 12:22 PM Hervé BOUTEMY >> > wrote: >> > > >> > > we're back at defining what our community support on every Maven parts >> > means >> > > >> > > to me, support for Maven core releases not only means that we would >> > release >> > > security bugfix if security issues were found (very low probability), >> > but more >> > > that we do *extra efforts on plugins to be checked for compatibility* >> > > >> > > Maven 3.0.x costs efforts for plugins compatibility, because of the old >> > very >> > > specific API >> > > starting with 3.1.x, API is org.eclipse.aether.*: AFAIK, no complexity >> > to have >> > > plugins compatibility >> > > >> > > that's why "deprecating Maven 3.0.x" to me is a reasonable choice (lower >> > > community efforts with minimal users impact) that will concretely mean >> > "produce >> > > plugins with Maven 3.1 as minimum", cleaning old code and tests for 3.0.x >> > > compatibility >> > > >> > > Regards, >> > > >> > > Hervé >> > > >> > > Le jeudi 16 avril 2020, 10:41:23 CEST Tibor Digana a écrit : >> > > > The Eclipse Aether looks like a strong argument. >> > > > If any user would open an issue to provide a fix on the top of Eclipse >> > > > Aether then we say 'no' already today in 3.7.0. >> > > > So the user has to switch to 3.5.0+ which would end up for him as the >> > > > same as deprecating 3.0.x - 3.3.x. >> > > > I know that it is a big extend, i understand that but this is >> > > > currently the outcome of my analysis. >> > > > >> > > > I don't know what you think about this view. >> > > > >> > > > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY >> > wrote: >> > > > > +1 to deprecate 3.0.x >> > > > > >> > > > > TLDR; no need to deprecate Eclipse Aether, which would mean >> > deprecating >> > > > > also 3.1.x, 3.2.x and 3.3.x >> > > > > >> > > > > details: >> > > > > "deprecate everything before the maven-resolver import" would mean >> > > > > deprecating up to 3.3.x [1] >> > > > > >> > > > > Given that maven-resolver has exactly the same API as Eclipse Aether >> > (in >> > > > > org.eclipse.aether java package) but just a change in Maven >> > coordinates >> > > > > (that are all filtered by Maven core class loading, then not really >> > an >> > > > > issue), I'm not convinced this is absolutely necessary to go to that >> > > > > extend >> > > > > >> > > > > what is really useful is to deprecate anything that is not in >> > > > > org.eclipse.aether Java package, because it is a nightmare in terms >> > of >> > > > > Java >> > > > > code compatibility: this means deprecating 3.0.x only [2], given the >> > > > > switch to Eclipse Aether has been done in 3.1.0 [3] >> > > > > And, for the record, the switch to Maven Artifact Resolver has been >> > done >> > > > > in >> > > > > 3.5.0 [4] >> > > > > >> > > > > Regards, >> > > > > >> > > > > Hervé >> > > > > >> > > > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html >> > > > > >> > > > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html >> > > > > >> > > > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html >> > > > > >> > > > > [4] >> > https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html >> > > > > >> > > > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit : >> > > > > > +100 >> > > > > > >> > > > > > I would deprecate everything before the maven-resolver import back >> > to >> > > > > > the >> > > > > > project while you are at it. Not sure exact version but 3.1x would >> > > > > > definitely on that list as well. Maybe also 3.2x >> > > > > > >> > > > > > Manfred >> > > > > > >> > > > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00): >> > > > > > > Some users still use Maven 3.0.5 and they require a support for >> > > > > > > compatibility reasons between nowadays Maven plugins and the >> > Maven >> > > > > > > 3.0.x. >> > > > > > > >> > > > > > > We have a couple of reasons to deprecate this version (JSR-330, >> > > > > > > Components injection, Logger) and we have discussed this issue in >> > > > > > > https://github.com/apache/maven-surefire/pull/274 >> > > > > > > >> > > > > > > Let's discuss it. >> > > > > > > >> > > > > > > Cheers >> > > > > > > Tibor17 >> > > > > > > >> > > > > > > >> > --------------------------------------------------------------------- >> > > > > > > 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 >> > > > > >> > > > > --------------------------------------------------------------------- >> > > > > 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 >> > > >> > >> > >> > -- >> > Cheers >> > Tibor >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > > > > > -- > Cheers > Tibor > > --------------------------------------------------------------------- > 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
