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 <[email protected]> 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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
