Hi Tibor, technically you are likely right but deprecating is not only technical, i'd say it is only 10% of the choice (even if it is what triggers the discussion). The biggest part for me is how it affects users. 3.5.x is only 3 years old so I think it is too early to deprecate it (guess we should target at least 5 years of support) so I think 3.3 can't be deprecated today but maybe in 1 or 2 years. That said we can stop supporting 3.3 for new version of plugins and only be reactive to backport a fix if needed (it is quite rare I think). This way we can move forward and not send a negative message for enterprises. In other words: we support >= 3.3 but plugin upgrades can target only > 3.5.
Wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 16 avr. 2020 à 10:41, Tibor Digana <tibordig...@apache.org> 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 <herve.bout...@free.fr> > 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 > > > > > -- > Cheers > Tibor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
