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
