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 <herve.bout...@free.fr> 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 <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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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

Reply via email to