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 <eolive...@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 <lukas.fel...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
