Closed FroMage closed 9 years ago
Well, I'll just make this move then.
Well what is the "debian ordering"? But although personally I don't like the "list of well-known qualifiers" because it seems very "personal" (some projects use letters: "1.2-A", "1.2-B", what happens when they get to "M"?) I agree that in the Java world they are most likely to stick to something that will work for Maven, so if that's what they use I'm okay with that.
The Debian ordering is described here: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version and was the only ordering I could find which was specified, and version-scheme-agnostic (which excludes OSGi ordering as nobody uses it in the real world).
What would be the impact on the OSGI compatibility, since OSGI versioning doesn't support that afaik ?
Impact? This is only about ordering versions that we already allow and that already exist in the wild. OSGi already cannot handle most Maven versions, so I didn't make it better or worse for OSGi.
Was reading a bit about this here: http://www.infoq.com/news/2012/04/osgi-snapshot And it at least explains why OSGi versions are so horrible.
Well, TBH I consider it way more normal that 1.2
> 1
, and my test of my implementation of the Maven spec confirms that it is the case, so either my implementation is wrong, or that quote is wrong:
In Maven, 1.2.3.2012 <= 1.2.3
And the Maven spec when comparing a number to null (the case in this example) says>
If integer==0 then equal, otherwise integer is newer
So that confirms that this article quote is wrong.
Yes, that confused me as well, I think it's a typo and he meant to say 1.2.3-2012 <= 1.2.3
(which is similar to examples he mentions later on)
Ah OK. But still the Maven spec would say that 2012
makes a new list with one integer, and to compare it to a list with a single null element, which again comes to comparing a number with null and and the number is newer.
but wouldn't the "-" put it in a sublist? And wasn't an empty "" at the end the same as having "-final"? (I must say I found that part in the document confusing, especially looking at the examples)
Yes we'd have [1, 2, 3, [2012]]
against [1, 2, 3]
and if we remove the parts which are equals, we're left with [2012] <=> null
which the spec says is the same as [2012] <=> [null]
=> 2012 <=> null
where the number is newer.
Oh wow it specifically mentions:
1.0 ==? 1.0-alpha: "" (or null) ==? "alpha" -> "4" ==? "1" -> 1.0 is newer
1.0 ==? 1.0-abc: "4" ==? "7-abc" -> 1.0-abc is newer
So if it's one of those "special" qualifiers it can be seen as "less" but if it's not it's seen as "more". Yew. But if that what's in use...
Ah yes, with strings it's different ;)
But that just shows how wrong that article is. It gets it twice wrong in the first paragraph. How can it go better after that?
That doesn't mean that his observation about OSGi versions being stupidly long because there's no way a pre-release version of 1.2-whatever-we-put-here
can be considered an older than 1.2
, so they are obliged to make it sort higher ASCII-wise -> 1.2-Zwhatever-we-put-here
isn't correct.
Wrap this one up please folks. I don't give a shit what the outcome is but let's have an outcome. Thanks.
Done.
I finally found the "spec" for Maven version ordering: https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
We could copy it instead of the current Debian ordering (the only one I found at the time which dealt with versions outside the
x.y.z
scope in a specified manner), on the basis that that's what most libraries adhere to, and it fixes a few issues that the Debian ordering does not support, such as:r01
<18.0
(guava)-alpha
and-final
suffixes that people use, like:1.0.2-RC
<1.0.2
WDYT?