You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Elliotte Rusty Harold <el...@ibiblio.org> on 2020/01/07 12:16:06 UTC
Version poll results
I've been looking at Maven 's version comparison algorithm: what it
does, what it's documented to do, and what it should do. I ran a quick
poll on my twitter feed to see what developers expect how version
strings such as 2.1.q and 2.1 are compared. That is, what's the higher
version? 2.1.q or 2.1?
https://twitter.com/elharo/status/1213457533358223361
2.1.q won in a landslide. This is, unfortunately, the opposite of what
Maven currently assumes. See
https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
to understand how.
This has real world consequences. xpp3:xpp3 for example uses letters
with the expectation that 1.4.1.c comes after 1.4.1. There are
probably other artifacts that use letters with these semantics too.
I'm about 90% convinced this is something we should fix. It's a
breaking change but I expect the high majority of devs who encounter
this would classify the existing behavior as a bug.
My main question is what version of Maven should we fix this in?
3.6.5? 3.7? 4.0? Thoughts?
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Robert Scholte <rf...@apache.org>.
I'd mark the Fix version as 4.0.x-candidate
On 7-1-2020 13:16:57, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
I've been looking at Maven 's version comparison algorithm: what it
does, what it's documented to do, and what it should do. I ran a quick
poll on my twitter feed to see what developers expect how version
strings such as 2.1.q and 2.1 are compared. That is, what's the higher
version? 2.1.q or 2.1?
https://twitter.com/elharo/status/1213457533358223361
2.1.q won in a landslide. This is, unfortunately, the opposite of what
Maven currently assumes. See
https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
to understand how.
This has real world consequences. xpp3:xpp3 for example uses letters
with the expectation that 1.4.1.c comes after 1.4.1. There are
probably other artifacts that use letters with these semantics too.
I'm about 90% convinced this is something we should fix. It's a
breaking change but I expect the high majority of devs who encounter
this would classify the existing behavior as a bug.
My main question is what version of Maven should we fix this in?
3.6.5? 3.7? 4.0? Thoughts?
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Manfred Moser <ma...@simpligility.com>.
Elliotte Rusty Harold wrote on 2020-01-07 13:38 (GMT -08:00):
> On Tue, Jan 7, 2020 at 4:00 PM Clemens Quoss <cl...@quoss.de> wrote:
>>
>> artifactId-version-classifier.jar
>>
>> How do i separate the classifier?
>>
>
> If all you have is the name of the jar, I don't think you can. You
> need the repo metadata or the coordinates or the pom.xml to tell
> whether google-cloud-firestore-0.41.0-beta.jar has the version
> 0.41.0-beta and no classifier or the version 0.41.0 and the classifier
> beta.
Correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Tue, Jan 7, 2020 at 4:00 PM Clemens Quoss <cl...@quoss.de> wrote:
>
> artifactId-version-classifier.jar
>
> How do i separate the classifier?
>
If all you have is the name of the jar, I don't think you can. You
need the repo metadata or the coordinates or the pom.xml to tell
whether google-cloud-firestore-0.41.0-beta.jar has the version
0.41.0-beta and no classifier or the version 0.41.0 and the classifier
beta.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Clemens Quoss <cl...@quoss.de>.
Hi Elliotte,
OK. I understand. Right now it is up to you to sync the doc to the
implementation.
Next step is to make improvements to the implementation.
All this with regard to how the version comparison is handled.
My question was:
Given a jar named
artifactId-version-classifier.jar
How do i separate the classifier?
Right now at our company we simply do not allow deployables to carry
classifiers. Because we can not separate them from the version.
We even had to customize the jbi-maven-plugin which by default always
adds the classifier 'installer' to the attached artifact entry of the
shared library zip file before it is deployed to nexus.
Cheers
Clemens
Am 07.01.2020 um 17:12 schrieb Elliotte Rusty Harold:
> This is what we currently claim to implement:
>
> https://maven.apache.org/pom.html#Version_Order_Specification
>
> However, there are bugs in both the spec and the implementation. That
> is, there are cases the spec does not describe and other parts where
> the spec is ambiguous. There also cases where the spec is unambiguous
> but the implementation in
> org.apache.maven.artifact.versioning.ComparableVersion does not do
> what the spec says.
>
> I'm working on rewriting the docs to at least clarify what should
> happen. https://issues.apache.org/jira/browse/MNG-6420 discusses some
> work to improve the implementation. However, we might want to take
> this opportunity to make a bigger change that's less surprising to
> users than the current behavior.
>
>
> On Tue, Jan 7, 2020 at 10:22 AM Clemens Quoss <cl...@quoss.de> wrote:
>> OK. Found it myself:
>>
>> https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html
>>
>> So classifier for sources, javadoc etc. Got it.
>>
>> But still: What is the alogorithm to separate version from classifier
>> when I only have the artifact name? Seems not possible, right? Or is
>> there a list of allowed classifiers?
>>
>> TIA
>>
>> Clemens
>>
>> Am 07.01.2020 um 16:16 schrieb Clemens Quoss:
>>> Consider this artifact:
>>>
>>> artifactId-1.0-alpha1-classifier.jar
>>>
>>> How to separate version (1.0-alpha1) from classifier (classifier), then?
>>>
>>> TIA
>>>
>>> Clemens
>>>
>>> Am 07.01.2020 um 16:12 schrieb Elliotte Rusty Harold:
>>>> Classifiers are a separate part of the coordinates and are never part
>>>> of the version string. "alpha1" is not a classifier and neither is
>>>> "q".
>>>>
>>>>
>>>>
>>>> On Tue, Jan 7, 2020 at 9:57 AM Clemens Quoss <cl...@quoss.de> wrote:
>>>>> Is 'q' considered a classifier or not? Classifier like 'alpha1',
>>>>> 'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
>>>>>
>>>>> With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
>>>>> artifactId-1.0.SNAPSHOT < ...
>>>>>
>>>>> Is there really a difference between putting a hyphen or a dot to
>>>>> separate classifier from version? If so, is my statement only right
>>>>> for
>>>>>
>>>>> artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
>>>>> artifactId-1.0-SNAPSHOT < ...? Please advise.
>>>>>
>>>>> I think, it is irrelevant if the classifier is separated by hyphen or
>>>>> dot. Everything after the version starting with an alphabetic
>>>>> character
>>>>> is a classifier, used to classify a pre-production version. The
>>>>> classifiers being in alphabetical order.
>>>>>
>>>>> That is why i never understood Spring working with versions like
>>>>> 2.1.RELEASE (being < 2.1).
>>>>>
>>>>> Regards
>>>>>
>>>>> Clemens
>>>>>
>>>>> Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
>>>>>> I've been looking at Maven 's version comparison algorithm: what it
>>>>>> does, what it's documented to do, and what it should do. I ran a quick
>>>>>> poll on my twitter feed to see what developers expect how version
>>>>>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
>>>>>> version? 2.1.q or 2.1?
>>>>>>
>>>>>> https://twitter.com/elharo/status/1213457533358223361
>>>>>>
>>>>>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
>>>>>> Maven currently assumes. See
>>>>>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
>>>>>>
>>>>>> to understand how.
>>>>>>
>>>>>> This has real world consequences. xpp3:xpp3 for example uses letters
>>>>>> with the expectation that 1.4.1.c comes after 1.4.1. There are
>>>>>> probably other artifacts that use letters with these semantics too.
>>>>>>
>>>>>> I'm about 90% convinced this is something we should fix. It's a
>>>>>> breaking change but I expect the high majority of devs who encounter
>>>>>> this would classify the existing behavior as a bug.
>>>>>>
>>>>>> My main question is what version of Maven should we fix this in?
>>>>>> 3.6.5? 3.7? 4.0? Thoughts?
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
This is what we currently claim to implement:
https://maven.apache.org/pom.html#Version_Order_Specification
However, there are bugs in both the spec and the implementation. That
is, there are cases the spec does not describe and other parts where
the spec is ambiguous. There also cases where the spec is unambiguous
but the implementation in
org.apache.maven.artifact.versioning.ComparableVersion does not do
what the spec says.
I'm working on rewriting the docs to at least clarify what should
happen. https://issues.apache.org/jira/browse/MNG-6420 discusses some
work to improve the implementation. However, we might want to take
this opportunity to make a bigger change that's less surprising to
users than the current behavior.
On Tue, Jan 7, 2020 at 10:22 AM Clemens Quoss <cl...@quoss.de> wrote:
>
> OK. Found it myself:
>
> https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html
>
> So classifier for sources, javadoc etc. Got it.
>
> But still: What is the alogorithm to separate version from classifier
> when I only have the artifact name? Seems not possible, right? Or is
> there a list of allowed classifiers?
>
> TIA
>
> Clemens
>
> Am 07.01.2020 um 16:16 schrieb Clemens Quoss:
> > Consider this artifact:
> >
> > artifactId-1.0-alpha1-classifier.jar
> >
> > How to separate version (1.0-alpha1) from classifier (classifier), then?
> >
> > TIA
> >
> > Clemens
> >
> > Am 07.01.2020 um 16:12 schrieb Elliotte Rusty Harold:
> >> Classifiers are a separate part of the coordinates and are never part
> >> of the version string. "alpha1" is not a classifier and neither is
> >> "q".
> >>
> >>
> >>
> >> On Tue, Jan 7, 2020 at 9:57 AM Clemens Quoss <cl...@quoss.de> wrote:
> >>> Is 'q' considered a classifier or not? Classifier like 'alpha1',
> >>> 'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
> >>>
> >>> With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
> >>> artifactId-1.0.SNAPSHOT < ...
> >>>
> >>> Is there really a difference between putting a hyphen or a dot to
> >>> separate classifier from version? If so, is my statement only right
> >>> for
> >>>
> >>> artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
> >>> artifactId-1.0-SNAPSHOT < ...? Please advise.
> >>>
> >>> I think, it is irrelevant if the classifier is separated by hyphen or
> >>> dot. Everything after the version starting with an alphabetic
> >>> character
> >>> is a classifier, used to classify a pre-production version. The
> >>> classifiers being in alphabetical order.
> >>>
> >>> That is why i never understood Spring working with versions like
> >>> 2.1.RELEASE (being < 2.1).
> >>>
> >>> Regards
> >>>
> >>> Clemens
> >>>
> >>> Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
> >>>> I've been looking at Maven 's version comparison algorithm: what it
> >>>> does, what it's documented to do, and what it should do. I ran a quick
> >>>> poll on my twitter feed to see what developers expect how version
> >>>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> >>>> version? 2.1.q or 2.1?
> >>>>
> >>>> https://twitter.com/elharo/status/1213457533358223361
> >>>>
> >>>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> >>>> Maven currently assumes. See
> >>>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> >>>>
> >>>> to understand how.
> >>>>
> >>>> This has real world consequences. xpp3:xpp3 for example uses letters
> >>>> with the expectation that 1.4.1.c comes after 1.4.1. There are
> >>>> probably other artifacts that use letters with these semantics too.
> >>>>
> >>>> I'm about 90% convinced this is something we should fix. It's a
> >>>> breaking change but I expect the high majority of devs who encounter
> >>>> this would classify the existing behavior as a bug.
> >>>>
> >>>> My main question is what version of Maven should we fix this in?
> >>>> 3.6.5? 3.7? 4.0? Thoughts?
> >>>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Clemens Quoss <cl...@quoss.de>.
OK. Found it myself:
https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html
So classifier for sources, javadoc etc. Got it.
But still: What is the alogorithm to separate version from classifier
when I only have the artifact name? Seems not possible, right? Or is
there a list of allowed classifiers?
TIA
Clemens
Am 07.01.2020 um 16:16 schrieb Clemens Quoss:
> Consider this artifact:
>
> artifactId-1.0-alpha1-classifier.jar
>
> How to separate version (1.0-alpha1) from classifier (classifier), then?
>
> TIA
>
> Clemens
>
> Am 07.01.2020 um 16:12 schrieb Elliotte Rusty Harold:
>> Classifiers are a separate part of the coordinates and are never part
>> of the version string. "alpha1" is not a classifier and neither is
>> "q".
>>
>>
>>
>> On Tue, Jan 7, 2020 at 9:57 AM Clemens Quoss <cl...@quoss.de> wrote:
>>> Is 'q' considered a classifier or not? Classifier like 'alpha1',
>>> 'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
>>>
>>> With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
>>> artifactId-1.0.SNAPSHOT < ...
>>>
>>> Is there really a difference between putting a hyphen or a dot to
>>> separate classifier from version? If so, is my statement only right
>>> for
>>>
>>> artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
>>> artifactId-1.0-SNAPSHOT < ...? Please advise.
>>>
>>> I think, it is irrelevant if the classifier is separated by hyphen or
>>> dot. Everything after the version starting with an alphabetic
>>> character
>>> is a classifier, used to classify a pre-production version. The
>>> classifiers being in alphabetical order.
>>>
>>> That is why i never understood Spring working with versions like
>>> 2.1.RELEASE (being < 2.1).
>>>
>>> Regards
>>>
>>> Clemens
>>>
>>> Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
>>>> I've been looking at Maven 's version comparison algorithm: what it
>>>> does, what it's documented to do, and what it should do. I ran a quick
>>>> poll on my twitter feed to see what developers expect how version
>>>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
>>>> version? 2.1.q or 2.1?
>>>>
>>>> https://twitter.com/elharo/status/1213457533358223361
>>>>
>>>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
>>>> Maven currently assumes. See
>>>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
>>>>
>>>> to understand how.
>>>>
>>>> This has real world consequences. xpp3:xpp3 for example uses letters
>>>> with the expectation that 1.4.1.c comes after 1.4.1. There are
>>>> probably other artifacts that use letters with these semantics too.
>>>>
>>>> I'm about 90% convinced this is something we should fix. It's a
>>>> breaking change but I expect the high majority of devs who encounter
>>>> this would classify the existing behavior as a bug.
>>>>
>>>> My main question is what version of Maven should we fix this in?
>>>> 3.6.5? 3.7? 4.0? Thoughts?
>>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Clemens Quoss <cl...@quoss.de>.
Consider this artifact:
artifactId-1.0-alpha1-classifier.jar
How to separate version (1.0-alpha1) from classifier (classifier), then?
TIA
Clemens
Am 07.01.2020 um 16:12 schrieb Elliotte Rusty Harold:
> Classifiers are a separate part of the coordinates and are never part
> of the version string. "alpha1" is not a classifier and neither is
> "q".
>
>
>
> On Tue, Jan 7, 2020 at 9:57 AM Clemens Quoss <cl...@quoss.de> wrote:
>> Is 'q' considered a classifier or not? Classifier like 'alpha1',
>> 'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
>>
>> With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
>> artifactId-1.0.SNAPSHOT < ...
>>
>> Is there really a difference between putting a hyphen or a dot to
>> separate classifier from version? If so, is my statement only right for
>>
>> artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
>> artifactId-1.0-SNAPSHOT < ...? Please advise.
>>
>> I think, it is irrelevant if the classifier is separated by hyphen or
>> dot. Everything after the version starting with an alphabetic character
>> is a classifier, used to classify a pre-production version. The
>> classifiers being in alphabetical order.
>>
>> That is why i never understood Spring working with versions like
>> 2.1.RELEASE (being < 2.1).
>>
>> Regards
>>
>> Clemens
>>
>> Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
>>> I've been looking at Maven 's version comparison algorithm: what it
>>> does, what it's documented to do, and what it should do. I ran a quick
>>> poll on my twitter feed to see what developers expect how version
>>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
>>> version? 2.1.q or 2.1?
>>>
>>> https://twitter.com/elharo/status/1213457533358223361
>>>
>>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
>>> Maven currently assumes. See
>>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
>>> to understand how.
>>>
>>> This has real world consequences. xpp3:xpp3 for example uses letters
>>> with the expectation that 1.4.1.c comes after 1.4.1. There are
>>> probably other artifacts that use letters with these semantics too.
>>>
>>> I'm about 90% convinced this is something we should fix. It's a
>>> breaking change but I expect the high majority of devs who encounter
>>> this would classify the existing behavior as a bug.
>>>
>>> My main question is what version of Maven should we fix this in?
>>> 3.6.5? 3.7? 4.0? Thoughts?
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
Classifiers are a separate part of the coordinates and are never part
of the version string. "alpha1" is not a classifier and neither is
"q".
On Tue, Jan 7, 2020 at 9:57 AM Clemens Quoss <cl...@quoss.de> wrote:
>
> Is 'q' considered a classifier or not? Classifier like 'alpha1',
> 'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
>
> With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
> artifactId-1.0.SNAPSHOT < ...
>
> Is there really a difference between putting a hyphen or a dot to
> separate classifier from version? If so, is my statement only right for
>
> artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
> artifactId-1.0-SNAPSHOT < ...? Please advise.
>
> I think, it is irrelevant if the classifier is separated by hyphen or
> dot. Everything after the version starting with an alphabetic character
> is a classifier, used to classify a pre-production version. The
> classifiers being in alphabetical order.
>
> That is why i never understood Spring working with versions like
> 2.1.RELEASE (being < 2.1).
>
> Regards
>
> Clemens
>
> Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
> > I've been looking at Maven 's version comparison algorithm: what it
> > does, what it's documented to do, and what it should do. I ran a quick
> > poll on my twitter feed to see what developers expect how version
> > strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> > version? 2.1.q or 2.1?
> >
> > https://twitter.com/elharo/status/1213457533358223361
> >
> > 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> > Maven currently assumes. See
> > https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> > to understand how.
> >
> > This has real world consequences. xpp3:xpp3 for example uses letters
> > with the expectation that 1.4.1.c comes after 1.4.1. There are
> > probably other artifacts that use letters with these semantics too.
> >
> > I'm about 90% convinced this is something we should fix. It's a
> > breaking change but I expect the high majority of devs who encounter
> > this would classify the existing behavior as a bug.
> >
> > My main question is what version of Maven should we fix this in?
> > 3.6.5? 3.7? 4.0? Thoughts?
> >
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Clemens Quoss <cl...@quoss.de>.
Is 'q' considered a classifier or not? Classifier like 'alpha1',
'beta2' and even 'SNAPSHOT' denote a pre-production version, IMHO.
With: artifactId-1.0.alpha1 < artifactId-1.0.beta2 < ... <
artifactId-1.0.SNAPSHOT < ...
Is there really a difference between putting a hyphen or a dot to
separate classifier from version? If so, is my statement only right for
artifactId-1.0-alpha1 < artifactId-1.0-beta2 < ... <
artifactId-1.0-SNAPSHOT < ...? Please advise.
I think, it is irrelevant if the classifier is separated by hyphen or
dot. Everything after the version starting with an alphabetic character
is a classifier, used to classify a pre-production version. The
classifiers being in alphabetical order.
That is why i never understood Spring working with versions like
2.1.RELEASE (being < 2.1).
Regards
Clemens
Am 07.01.2020 um 13:16 schrieb Elliotte Rusty Harold:
> I've been looking at Maven 's version comparison algorithm: what it
> does, what it's documented to do, and what it should do. I ran a quick
> poll on my twitter feed to see what developers expect how version
> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> version? 2.1.q or 2.1?
>
> https://twitter.com/elharo/status/1213457533358223361
>
> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> Maven currently assumes. See
> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> to understand how.
>
> This has real world consequences. xpp3:xpp3 for example uses letters
> with the expectation that 1.4.1.c comes after 1.4.1. There are
> probably other artifacts that use letters with these semantics too.
>
> I'm about 90% convinced this is something we should fix. It's a
> breaking change but I expect the high majority of devs who encounter
> this would classify the existing behavior as a bug.
>
> My main question is what version of Maven should we fix this in?
> 3.6.5? 3.7? 4.0? Thoughts?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Manfred Moser <ma...@simpligility.com>.
Its part of the spec.. sure.However only the Maven spec .. and different specs and tools might behave differently. The Maven repository format and related aspects are used by MANY more tools than just Maven.
Using the short version 2.1 causes issues such as mentioned earlier for no real benefit - so in the interest of making it more user friendly and explicit I advocate for just being explicit and using 2.1.0
Manfred
Matt Foley wrote on 2020-01-08 12:36 (GMT -08:00):
>>> So do NOT use a version like 2.1 .. instead use 2.1.0.
>
> The fact that 2.1 is identical to 2.1.0 is part of the spec, unambiguous, and
> quite important for expected behavior IMHO. See "Trimming Examples" in
> https://maven.apache.org/pom.html#Version_Order_Specification
> <https://maven.apache.org/pom.html#Version_Order_Specification>
>
> Thanks,
> —Matt
> —————————
> Open Source Technologies @
>
>
> On Jan 7, 2020, at 1:29 PM, Manfred Moser <ma...@simpligility.com> wrote:
>
> To be honest I dont think this needs fixing on the Maven side. If we change
> behavior we just break other approaches.
>
> Instead users that want to use semver with three digits and want logic ordering
> should just do so.
>
> So do NOT use a version like 2.1 .. instead use 2.1.0.
>
> Problem solved.
>
> Also .. beyond the three digit semver usage .. dont assume anything beyond
> purely alphanumeric sort to work.
>
> And of course dont ever do something like "latest", which is so popular in
> other ecosystems like Docker or npm since you are just introducing a quicksand
> scenario for your users.
> E.g. latest release by date for example could be a patch release of an lower
> version...
>
> manfred
>
> Elliotte Rusty Harold wrote on 2020-01-07 04:16 (GMT -08:00):
>
>> I've been looking at Maven 's version comparison algorithm: what it
>> does, what it's documented to do, and what it should do. I ran a quick
>> poll on my twitter feed to see what developers expect how version
>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
>> version? 2.1.q or 2.1?
>>
>> https://twitter.com/elharo/status/1213457533358223361
>>
>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
>> Maven currently assumes. See
>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
>> to understand how.
>>
>> This has real world consequences. xpp3:xpp3 for example uses letters
>> with the expectation that 1.4.1.c comes after 1.4.1. There are
>> probably other artifacts that use letters with these semantics too.
>>
>> I'm about 90% convinced this is something we should fix. It's a
>> breaking change but I expect the high majority of devs who encounter
>> this would classify the existing behavior as a bug.
>>
>> My main question is what version of Maven should we fix this in?
>> 3.6.5? 3.7? 4.0? Thoughts?
>>
>> --
>> Elliotte Rusty Harold
>> elharo@ibiblio.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Matt Foley <ma...@apache.org>.
>> So do NOT use a version like 2.1 .. instead use 2.1.0.
The fact that 2.1 is identical to 2.1.0 is part of the spec, unambiguous, and quite important for expected behavior IMHO. See "Trimming Examples" in https://maven.apache.org/pom.html#Version_Order_Specification <https://maven.apache.org/pom.html#Version_Order_Specification>
Thanks,
—Matt
—————————
Open Source Technologies @
On Jan 7, 2020, at 1:29 PM, Manfred Moser <ma...@simpligility.com> wrote:
To be honest I dont think this needs fixing on the Maven side. If we change behavior we just break other approaches.
Instead users that want to use semver with three digits and want logic ordering should just do so.
So do NOT use a version like 2.1 .. instead use 2.1.0.
Problem solved.
Also .. beyond the three digit semver usage .. dont assume anything beyond purely alphanumeric sort to work.
And of course dont ever do something like "latest", which is so popular in other ecosystems like Docker or npm since you are just introducing a quicksand scenario for your users.
E.g. latest release by date for example could be a patch release of an lower version...
manfred
Elliotte Rusty Harold wrote on 2020-01-07 04:16 (GMT -08:00):
> I've been looking at Maven 's version comparison algorithm: what it
> does, what it's documented to do, and what it should do. I ran a quick
> poll on my twitter feed to see what developers expect how version
> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> version? 2.1.q or 2.1?
>
> https://twitter.com/elharo/status/1213457533358223361
>
> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> Maven currently assumes. See
> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> to understand how.
>
> This has real world consequences. xpp3:xpp3 for example uses letters
> with the expectation that 1.4.1.c comes after 1.4.1. There are
> probably other artifacts that use letters with these semantics too.
>
> I'm about 90% convinced this is something we should fix. It's a
> breaking change but I expect the high majority of devs who encounter
> this would classify the existing behavior as a bug.
>
> My main question is what version of Maven should we fix this in?
> 3.6.5? 3.7? 4.0? Thoughts?
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version poll results
Posted by Manfred Moser <ma...@simpligility.com>.
To be honest I dont think this needs fixing on the Maven side. If we change behavior we just break other approaches.
Instead users that want to use semver with three digits and want logic ordering should just do so.
So do NOT use a version like 2.1 .. instead use 2.1.0.
Problem solved.
Also .. beyond the three digit semver usage .. dont assume anything beyond purely alphanumeric sort to work.
And of course dont ever do something like "latest", which is so popular in other ecosystems like Docker or npm since you are just introducing a quicksand scenario for your users.
E.g. latest release by date for example could be a patch release of an lower version...
manfred
Elliotte Rusty Harold wrote on 2020-01-07 04:16 (GMT -08:00):
> I've been looking at Maven 's version comparison algorithm: what it
> does, what it's documented to do, and what it should do. I ran a quick
> poll on my twitter feed to see what developers expect how version
> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> version? 2.1.q or 2.1?
>
> https://twitter.com/elharo/status/1213457533358223361
>
> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> Maven currently assumes. See
> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> to understand how.
>
> This has real world consequences. xpp3:xpp3 for example uses letters
> with the expectation that 1.4.1.c comes after 1.4.1. There are
> probably other artifacts that use letters with these semantics too.
>
> I'm about 90% convinced this is something we should fix. It's a
> breaking change but I expect the high majority of devs who encounter
> this would classify the existing behavior as a bug.
>
> My main question is what version of Maven should we fix this in?
> 3.6.5? 3.7? 4.0? Thoughts?
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org