Proposal to deprecate Maven 3.0.x

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to deprecate Maven 3.0.x

Sesterhenn, Jörg
Hi, please let me give you a users perspective:

1) deprecate *every* version that is not likely to get an important
issue (even if it only concerns a core plugin) fixed timely - no matter
how old it is. Anything else is lying to yourself and your users about
your capability. There is no shame in not beeing able to support a
version after the next one was released given that this support is not
beeing paid for.

2) think about (and communicate) support cycles before you introduce
breaking changes. Only provide *one *LTS-Version if you feel you can
handle that commitment.

4) try to support usecases rather than plugins - if something old needs
to be droped you can provide a new solution instead of dragging old
stuff with you

5) try and do contnuous delivery. If you can not because of the way that
plugins are kept apart from maven try at least to introduce regular
releasetrains with small changesets. maybe eclipse could step in and
help with that ?

I believe all this would help users and developers to deal with changes
in a more professional way. This could also free up time to introduce
new concepts and features that are long overdue.

Regards

Jörg Sesterhenn

--
Jörg Sesterhenn
Referent

Debeka Krankenversicherungsverein a. G.
Debeka Lebensversicherungsverein a. G.
Debeka Allgemeine Versicherung AG
Debeka Pensionskasse AG
Debeka Bausparkasse AG

Abteilung IT-Grundlagen & -Engineering
IT-Prozesse und Automatisierung (IE/P)
56058 Koblenz

Telefon: (02 61) 4 98 – 14 55
Telefax: (02 61) 4 98 – 15 41

E-Mail: [hidden email]
Internet: www.debeka.de

Besuchen Sie uns auch in sozialen Netzwerken.
Unsere Adressen finden Sie hier: www.debeka.de/socialmedia

Pflichtangaben der Debeka-Unternehmen
gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

rfscholte
There should be a balance between the size of the community to support and the effort it requires to maintain the code.
Maven 3.1.0 broke the API because Aether classes ended up in a different package, so for plugins we had to introduce maven-artifact-transfer to support all M3 versions.
Maven 3.1.0 introduced JSR330 (@Inject) support.
Since then there have been no critical changes, improvements were mostly in the implementation.
For a Maven plugin there's no difference in the API between 3.1.0 and 3.6.3, but by requiring e.g 3.6.3 you'll reduce the size of the community.
From a technical point of view there's no reason to do this.
From a strategic point of view one could decide to push it to a higher version to motivate users to upgrade Maven.
IMO it should not be the plugins to enforce this. Plugins should require a newer version if they depend on a specific feature or change.

With the idea of largest community support for least amount of effort I'd go for 3.1.0

Robert

On 17-4-2020 03:06:53, Manfred Moser <[hidden email]> wrote:
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 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 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: [hidden email]
>> > > > > > > For additional commands, e-mail: [hidden email]
>> > > > > >
>> > > > > >
>> > ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail: [hidden email]
>> > > > > > For additional commands, e-mail: [hidden email]
>> > > > >
>> > > > > ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: [hidden email]
>> > > > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> >
>> >
>> > --
>> > Cheers
>> > Tibor
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>
>
>
> --
> Cheers
> Tibor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]