You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by lu...@quatico.com on 2020/10/02 07:05:48 UTC
Maven Plugins & Confusing Versioning
Hi All & Maven Devs
My name is Lukas, I'm a software engineer working at some very little
company located in Switzerland (called Quatico).
I wanted to let you know that the versioning that is used in (as far as I
can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
very confusing <to the world>.
I can see on the corresponding Website (e.g.
https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
these milestone releases are declared to be stable.
My company did not upgrade plugin versions basically for some years now
because (when just seeing the version itself) decided "Nope, its only a
milestone, thus not stable".
So in contrast to the maven plugin versions, the community is pretty clear
about what x.y.z-M1 means: It's a pre-release for early testing purposes
(e.g. see you "partner" projects explanation for it here
https://en.wikipedia.org/wiki/Software_versioning ).
I don't want to complain (I now know the versions are stable) but the usage
of your new version would probably pike much quicker around the work if you
followed the "regular" versioning scheme.
Why use the Major part (3), then completely ignoring Minor (always 0) and
Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
see an advantage in it.
Hope the input might help!
Cheers
Lukas
Re: Maven Plugins & Confusing Versioning
Posted by Greg Chabala <gr...@gmail.com>.
I agree with other users' sentiments here. I was ignoring the milestone
releases for a long time as though they were unfinished and unsuitable for
stable use.
Additionally, I have my version checking plugin configured to ignore
milestones based on how they are used by other projects, and there's little
point to making an exception for Maven plugin versions.
Greg Chabala
On Tue, Oct 6, 2020 at 9:13 AM Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 6, 2020 at 7:46 AM Thomas Broyer <t....@gmail.com> wrote:
>
> > (sorry for the delay)
> >
> > On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise <kh...@gmx.de>
> > wrote:
> >
> > > Hi,
> > >
> > > On 03.10.20 11:47, Thomas Broyer wrote:
> > > > Wait, you mean that you don't even follow your own rules for versions
> > ⁉️
> > > > where milestones sit between beta and RC versions.
> > >
> > > Can you explain which rules you are referencing?
> > >
> >
> > I meant those:
> > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
> >
> >
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
> >
> >
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
> > and as shown by that command:
> > $ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
> > 3.0.0-RC1 3.0.0
> > Display parameters as parsed by Maven (in canonical form) and comparison
> > result:
> > 1. 3.0.0-beta1 == 3-beta-1
> > 3.0.0-beta1 < 3.0.0-M1
> > 2. 3.0.0-M1 == 3-milestone-1
> > 3.0.0-M1 < 3.0.0-RC1
> > 3. 3.0.0-RC1 == 3-rc-1
> > 3.0.0-RC1 < 3.0.0
> > 4. 3.0.0 == 3
> >
> > The part M... is from our perspective a milestone in direction to a
> > > particular set of features that has nothing to do with not stable...
> for
> >
> > example see https://maven.apache.org/surefire/maven-failsafe-plugin/
> >
> >
> >
> > I'm for example using maven-release-plugin:3.0.0-M1 in production...
> > > You can take a look into the CI results
> > > (
> > >
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> > > )
> > > or the tests which are running on them:
> > >
> > >
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
> > >
> > >
> > > The question based on that is comming up:
> > >
> > > What do you define as "unstable" ? All of those plugins are already
> > > running very long (I mean very long) in production environments ... so
> > > of course sometimes people find bugs ...
> > >
> > >
> > > As Enrico alrady mentioned ...we don't release unstable plugins... (but
> > > it drills down to the question: What is a unstable plugin?)
> >
> >
> > The question to me is: should anyone use a milestone version? What are
> the
> > "guarantees" compared to a "final" version?
> > If you're saying that there's no reason not to use a milestone in
> > production, that it's guaranteed to work just as well as a "final"
> version,
> > then why isn't it labelled "final"?
> > When I see a milestone version (or any "prerelease" version), I'm
> thinking
> > "OK, they're still working on it (hey, it's not even a release
> candidate),
> > let's use the latest "final" release" (in this case 2.5.3;
> >
> >
> https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
> > ).
> > I also expect that if there are bugs in that latest "final" release that
> > possibly there could be a "point release" fixing them (2.5.4) before the
> > next major version is "stable" (3.0.0)
> > So of course such a "prerelease" could be "stable enough" to be used in
> > production, but who knows in which ways it could possibly break? or
> change
> > in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
> > Only people following the plugin's development closely can know.
> >
> > So, if the message you want to send is "use that 3.0.something version,
> > it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
> > 3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
> > 3.0.0-M1.
> > If you want to make it clear that some feature is not "stable" yet (in
> its
> > API/configuration, or possibly buggy), then you could add warnings in the
> > docs and even issue a warning at runtime if it's being used (I know
> people
> > don't pay attention to warnings, and I think mostly because Maven output
> is
> > quite/too verbose, but still).
> >
>
> From a user's POV, I agree that the messaging on "M" releases is unclear.
> To me a milestone release is not stable, it's just a different way of
> saying "alpha" or "beta".
>
> Gary
>
> >
> > --
> > Thomas Broyer
> > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/> <
> > http://xn--nna.ma.xn--bwa-xxb.je/>
> >
>
Re: Maven Plugins & Confusing Versioning
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 6, 2020 at 7:46 AM Thomas Broyer <t....@gmail.com> wrote:
> (sorry for the delay)
>
> On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
> > Hi,
> >
> > On 03.10.20 11:47, Thomas Broyer wrote:
> > > Wait, you mean that you don't even follow your own rules for versions
> ⁉️
> > > where milestones sit between beta and RC versions.
> >
> > Can you explain which rules you are referencing?
> >
>
> I meant those:
> https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
>
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
>
> https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
> and as shown by that command:
> $ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
> 3.0.0-RC1 3.0.0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 3.0.0-beta1 == 3-beta-1
> 3.0.0-beta1 < 3.0.0-M1
> 2. 3.0.0-M1 == 3-milestone-1
> 3.0.0-M1 < 3.0.0-RC1
> 3. 3.0.0-RC1 == 3-rc-1
> 3.0.0-RC1 < 3.0.0
> 4. 3.0.0 == 3
>
> The part M... is from our perspective a milestone in direction to a
> > particular set of features that has nothing to do with not stable... for
>
> example see https://maven.apache.org/surefire/maven-failsafe-plugin/
>
>
>
> I'm for example using maven-release-plugin:3.0.0-M1 in production...
> > You can take a look into the CI results
> > (
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> > )
> > or the tests which are running on them:
> >
> >
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
> >
> >
> > The question based on that is comming up:
> >
> > What do you define as "unstable" ? All of those plugins are already
> > running very long (I mean very long) in production environments ... so
> > of course sometimes people find bugs ...
> >
> >
> > As Enrico alrady mentioned ...we don't release unstable plugins... (but
> > it drills down to the question: What is a unstable plugin?)
>
>
> The question to me is: should anyone use a milestone version? What are the
> "guarantees" compared to a "final" version?
> If you're saying that there's no reason not to use a milestone in
> production, that it's guaranteed to work just as well as a "final" version,
> then why isn't it labelled "final"?
> When I see a milestone version (or any "prerelease" version), I'm thinking
> "OK, they're still working on it (hey, it's not even a release candidate),
> let's use the latest "final" release" (in this case 2.5.3;
>
> https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
> ).
> I also expect that if there are bugs in that latest "final" release that
> possibly there could be a "point release" fixing them (2.5.4) before the
> next major version is "stable" (3.0.0)
> So of course such a "prerelease" could be "stable enough" to be used in
> production, but who knows in which ways it could possibly break? or change
> in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
> Only people following the plugin's development closely can know.
>
> So, if the message you want to send is "use that 3.0.something version,
> it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
> 3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
> 3.0.0-M1.
> If you want to make it clear that some feature is not "stable" yet (in its
> API/configuration, or possibly buggy), then you could add warnings in the
> docs and even issue a warning at runtime if it's being used (I know people
> don't pay attention to warnings, and I think mostly because Maven output is
> quite/too verbose, but still).
>
From a user's POV, I agree that the messaging on "M" releases is unclear.
To me a milestone release is not stable, it's just a different way of
saying "alpha" or "beta".
Gary
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>
Re: Maven Plugins & Confusing Versioning
Posted by Robert Scholte <rf...@apache.org>.
There's a migration plan for moving plugin from Maven2 to Maven3[1]
As long as these steps haven't been finished, but people expect us to do releases due to bugfixes or improvements, we must use some pre 3.0.0 as version, hence the milestones.
For the plugins that are marked as M, most I can explain (if I recall them correctly):
install+deploy: issues with different implementations of Aether/Maven Resolver
enforcer: issues with dependency graph
release: new architecture
surefire/failsafe: new architecture
In all cases, the plugin should still work as 2.x (unless parameters has been replaced/removed, going for a new major is the only opportunity to makes these kind of changes).
thanks,
Robert
[1] https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
On 6-10-2020 13:46:52, Thomas Broyer <t....@gmail.com> wrote:
(sorry for the delay)
On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise
wrote:
> Hi,
>
> On 03.10.20 11:47, Thomas Broyer wrote:
> > Wait, you mean that you don't even follow your own rules for versions ⁉️
> > where milestones sit between beta and RC versions.
>
> Can you explain which rules you are referencing?
>
I meant those:
https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
and as shown by that command:
$ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
3.0.0-RC1 3.0.0
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 3.0.0-beta1 == 3-beta-1
3.0.0-beta1 < 3.0.0-M1
2. 3.0.0-M1 == 3-milestone-1
3.0.0-M1 < 3.0.0-RC1
3. 3.0.0-RC1 == 3-rc-1
3.0.0-RC1 < 3.0.0
4. 3.0.0 == 3
The part M... is from our perspective a milestone in direction to a
> particular set of features that has nothing to do with not stable... for
example see https://maven.apache.org/surefire/maven-failsafe-plugin/
I'm for example using maven-release-plugin:3.0.0-M1 in production...
> You can take a look into the CI results
> (
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> )
> or the tests which are running on them:
>
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
>
>
> The question based on that is comming up:
>
> What do you define as "unstable" ? All of those plugins are already
> running very long (I mean very long) in production environments ... so
> of course sometimes people find bugs ...
>
>
> As Enrico alrady mentioned ...we don't release unstable plugins... (but
> it drills down to the question: What is a unstable plugin?)
The question to me is: should anyone use a milestone version? What are the
"guarantees" compared to a "final" version?
If you're saying that there's no reason not to use a milestone in
production, that it's guaranteed to work just as well as a "final" version,
then why isn't it labelled "final"?
When I see a milestone version (or any "prerelease" version), I'm thinking
"OK, they're still working on it (hey, it's not even a release candidate),
let's use the latest "final" release" (in this case 2.5.3;
https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
).
I also expect that if there are bugs in that latest "final" release that
possibly there could be a "point release" fixing them (2.5.4) before the
next major version is "stable" (3.0.0)
So of course such a "prerelease" could be "stable enough" to be used in
production, but who knows in which ways it could possibly break? or change
in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
Only people following the plugin's development closely can know.
So, if the message you want to send is "use that 3.0.something version,
it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
3.0.0-M1.
If you want to make it clear that some feature is not "stable" yet (in its
API/configuration, or possibly buggy), then you could add warnings in the
docs and even issue a warning at runtime if it's being used (I know people
don't pay attention to warnings, and I think mostly because Maven output is
quite/too verbose, but still).
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Re: Maven Plugins & Confusing Versioning
Posted by Thomas Broyer <t....@gmail.com>.
(sorry for the delay)
On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> Hi,
>
> On 03.10.20 11:47, Thomas Broyer wrote:
> > Wait, you mean that you don't even follow your own rules for versions ⁉️
> > where milestones sit between beta and RC versions.
>
> Can you explain which rules you are referencing?
>
I meant those:
https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
and as shown by that command:
$ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
3.0.0-RC1 3.0.0
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 3.0.0-beta1 == 3-beta-1
3.0.0-beta1 < 3.0.0-M1
2. 3.0.0-M1 == 3-milestone-1
3.0.0-M1 < 3.0.0-RC1
3. 3.0.0-RC1 == 3-rc-1
3.0.0-RC1 < 3.0.0
4. 3.0.0 == 3
The part M... is from our perspective a milestone in direction to a
> particular set of features that has nothing to do with not stable... for
example see https://maven.apache.org/surefire/maven-failsafe-plugin/
I'm for example using maven-release-plugin:3.0.0-M1 in production...
> You can take a look into the CI results
> (
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> )
> or the tests which are running on them:
>
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
>
>
> The question based on that is comming up:
>
> What do you define as "unstable" ? All of those plugins are already
> running very long (I mean very long) in production environments ... so
> of course sometimes people find bugs ...
>
>
> As Enrico alrady mentioned ...we don't release unstable plugins... (but
> it drills down to the question: What is a unstable plugin?)
The question to me is: should anyone use a milestone version? What are the
"guarantees" compared to a "final" version?
If you're saying that there's no reason not to use a milestone in
production, that it's guaranteed to work just as well as a "final" version,
then why isn't it labelled "final"?
When I see a milestone version (or any "prerelease" version), I'm thinking
"OK, they're still working on it (hey, it's not even a release candidate),
let's use the latest "final" release" (in this case 2.5.3;
https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
).
I also expect that if there are bugs in that latest "final" release that
possibly there could be a "point release" fixing them (2.5.4) before the
next major version is "stable" (3.0.0)
So of course such a "prerelease" could be "stable enough" to be used in
production, but who knows in which ways it could possibly break? or change
in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
Only people following the plugin's development closely can know.
So, if the message you want to send is "use that 3.0.something version,
it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
3.0.0-M1.
If you want to make it clear that some feature is not "stable" yet (in its
API/configuration, or possibly buggy), then you could add warnings in the
docs and even issue a warning at runtime if it's being used (I know people
don't pay attention to warnings, and I think mostly because Maven output is
quite/too verbose, but still).
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
Re: Maven Plugins & Confusing Versioning
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 03.10.20 11:47, Thomas Broyer wrote:
> Wait, you mean that you don't even follow your own rules for versions ⁉️
> where milestones sit between beta and RC versions.
Can you explain which rules you are referencing?
We are doing that for a very long time... The point not using RC's is
simply we do not see any advantage over a 3.1.2 ?
we usually release a plugin lets say 3.1.0 .. ..
So now someone finds a bug that means we will release 3.1.1 etc. In this
case releasing an RC1 would not help here and would produce a
intermediate release 3.1.1-RC1 ... which in the end finally has no
difference to 3.1.1 ? So no advantage only formal steps (vote's etc.)..
The part M... is from our perspective a milestone in direction to a
particular set of features that has nothing to do with not stable... for
example see https://maven.apache.org/surefire/maven-failsafe-plugin/
I'm for example using maven-release-plugin:3.0.0-M1 in production...
You can take a look into the CI results
(https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/)
or the tests which are running on them:
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
The question based on that is comming up:
What do you define as "unstable" ? All of those plugins are already
running very long (I mean very long) in production environments ... so
of course sometimes people find bugs ...
As Enrico alrady mentioned ...we don't release unstable plugins... (but
it drills down to the question: What is a unstable plugin?)
Kind regards
Karl Heinz Marbaise
>
> Le sam. 3 oct. 2020 à 09:57, Enrico Olivelli <eo...@gmail.com> a écrit :
>
>> Lukas,
>> The general rule is that we are not releasing unstable versions so it is
>> generally safe and good to upgrade to lasted version.
>>
>> The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x
>> than it should work with Maven 3. But it was released when the reference
>> Maven version was 2.x)
>>
>> The Mx suffix is only an internal version to the dev team of Maven. We mean
>> that it is a milestone in a sense that we would have wanted to deliver a
>> feature that is not implemented completely yet.
>> You should care about that only of you write extensions that depend of that
>> specific plugin.
>>
>> We are usually cutting versions only from the master branch and the master
>> branch is continuously tested against a big matrix of OSs, Maven versions
>> and Java version.
>>
>> I hope that helps
>> Enrico
>>
>> Il Sab 3 Ott 2020, 09:30 <lu...@quatico.com> ha scritto:
>>
>>> Hi All & Maven Devs
>>>
>>>
>>>
>>> My name is Lukas, I'm a software engineer working at some very little
>>> company located in Switzerland (called Quatico).
>>>
>>> I wanted to let you know that the versioning that is used in (as far as I
>>> can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
>>> very confusing <to the world>.
>>>
>>> I can see on the corresponding Website (e.g.
>>> https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
>>> these milestone releases are declared to be stable.
>>>
>>>
>>>
>>> My company did not upgrade plugin versions basically for some years now
>>> because (when just seeing the version itself) decided "Nope, its only a
>>> milestone, thus not stable".
>>>
>>> So in contrast to the maven plugin versions, the community is pretty
>> clear
>>> about what x.y.z-M1 means: It's a pre-release for early testing purposes
>>> (e.g. see you "partner" projects explanation for it here
>>> https://en.wikipedia.org/wiki/Software_versioning ).
>>>
>>>
>>>
>>> I don't want to complain (I now know the versions are stable) but the
>> usage
>>> of your new version would probably pike much quicker around the work if
>> you
>>> followed the "regular" versioning scheme.
>>>
>>> Why use the Major part (3), then completely ignoring Minor (always 0) and
>>> Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
>>> see an advantage in it.
>>>
>>>
>>>
>>> Hope the input might help!
>>>
>>>
>>>
>>> Cheers
>>>
>>> Lukas
>>>
>>>
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Plugins & Confusing Versioning
Posted by Thomas Broyer <t....@gmail.com>.
Wait, you mean that you don't even follow your own rules for versions ⁉️
where milestones sit between beta and RC versions.
Le sam. 3 oct. 2020 à 09:57, Enrico Olivelli <eo...@gmail.com> a écrit :
> Lukas,
> The general rule is that we are not releasing unstable versions so it is
> generally safe and good to upgrade to lasted version.
>
> The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x
> than it should work with Maven 3. But it was released when the reference
> Maven version was 2.x)
>
> The Mx suffix is only an internal version to the dev team of Maven. We mean
> that it is a milestone in a sense that we would have wanted to deliver a
> feature that is not implemented completely yet.
> You should care about that only of you write extensions that depend of that
> specific plugin.
>
> We are usually cutting versions only from the master branch and the master
> branch is continuously tested against a big matrix of OSs, Maven versions
> and Java version.
>
> I hope that helps
> Enrico
>
> Il Sab 3 Ott 2020, 09:30 <lu...@quatico.com> ha scritto:
>
> > Hi All & Maven Devs
> >
> >
> >
> > My name is Lukas, I'm a software engineer working at some very little
> > company located in Switzerland (called Quatico).
> >
> > I wanted to let you know that the versioning that is used in (as far as I
> > can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
> > very confusing <to the world>.
> >
> > I can see on the corresponding Website (e.g.
> > https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
> > these milestone releases are declared to be stable.
> >
> >
> >
> > My company did not upgrade plugin versions basically for some years now
> > because (when just seeing the version itself) decided "Nope, its only a
> > milestone, thus not stable".
> >
> > So in contrast to the maven plugin versions, the community is pretty
> clear
> > about what x.y.z-M1 means: It's a pre-release for early testing purposes
> > (e.g. see you "partner" projects explanation for it here
> > https://en.wikipedia.org/wiki/Software_versioning ).
> >
> >
> >
> > I don't want to complain (I now know the versions are stable) but the
> usage
> > of your new version would probably pike much quicker around the work if
> you
> > followed the "regular" versioning scheme.
> >
> > Why use the Major part (3), then completely ignoring Minor (always 0) and
> > Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
> > see an advantage in it.
> >
> >
> >
> > Hope the input might help!
> >
> >
> >
> > Cheers
> >
> > Lukas
> >
> >
> >
> >
>
Re: Maven Plugins & Confusing Versioning
Posted by Enrico Olivelli <eo...@gmail.com>.
Lukas,
The general rule is that we are not releasing unstable versions so it is
generally safe and good to upgrade to lasted version.
The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x
than it should work with Maven 3. But it was released when the reference
Maven version was 2.x)
The Mx suffix is only an internal version to the dev team of Maven. We mean
that it is a milestone in a sense that we would have wanted to deliver a
feature that is not implemented completely yet.
You should care about that only of you write extensions that depend of that
specific plugin.
We are usually cutting versions only from the master branch and the master
branch is continuously tested against a big matrix of OSs, Maven versions
and Java version.
I hope that helps
Enrico
Il Sab 3 Ott 2020, 09:30 <lu...@quatico.com> ha scritto:
> Hi All & Maven Devs
>
>
>
> My name is Lukas, I'm a software engineer working at some very little
> company located in Switzerland (called Quatico).
>
> I wanted to let you know that the versioning that is used in (as far as I
> can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
> very confusing <to the world>.
>
> I can see on the corresponding Website (e.g.
> https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
> these milestone releases are declared to be stable.
>
>
>
> My company did not upgrade plugin versions basically for some years now
> because (when just seeing the version itself) decided "Nope, its only a
> milestone, thus not stable".
>
> So in contrast to the maven plugin versions, the community is pretty clear
> about what x.y.z-M1 means: It's a pre-release for early testing purposes
> (e.g. see you "partner" projects explanation for it here
> https://en.wikipedia.org/wiki/Software_versioning ).
>
>
>
> I don't want to complain (I now know the versions are stable) but the usage
> of your new version would probably pike much quicker around the work if you
> followed the "regular" versioning scheme.
>
> Why use the Major part (3), then completely ignoring Minor (always 0) and
> Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
> see an advantage in it.
>
>
>
> Hope the input might help!
>
>
>
> Cheers
>
> Lukas
>
>
>
>