Re: Version poll results

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

Re: Version poll results

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 <[hidden email]> 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
[hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: Version poll results

Clemens Quoss
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
>

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