Hey @U08QZ7Y5S & thanks for bringing this up, I don’t think it was a known issue. We use version-clj for sorting versions in most places. It might be that we don’t for this particular thing (a bug) or that version-clj simply doesn’t agree with this kind of versioning scheme 😄

Makes sense. Would it be helpful to open a ticket?

So we use this file to determine the latest release version: http://repo.clojars.org/lambdaisland/kaocha/maven-metadata.xml

(and we don't use version-clj contrary to what I said earlier)

Oh, interesting. So maybe it's some kind of bug in the way they deployed that jar file. I'll bug the kaocha folks about it, thanks for the info!

I think the 0.0-N pattern is just not something Maven deals with very well

cc @U07FP7QJ0

so... this is probably because I screwed up. When I created kaocha-junit-xml I copied the pom over from kaocha and forgot to update the project name. So when I did the first release of kaocha-junit-xml it actually pushed it to clojars as kaocha 0.0-7...

I'll push a new kaocha, that should make the problem go away

However in repositories.clj line 106 and onwards we could just extract all the listed versions and sort them using version-clj a quick REPL test seems to indicate that version-clj would handle this correctly

Awesome,t hanks

the 0.0-N pattern is what clojurescript used before they switched to following Clojure versions, that's where I got the idea.

Interesting... Well I'd be happy to accept a PR to support this. I think it should be a fairly easy thing that can be easily tested from the REPL as well (the repositories namespace doesn't require any system to be started etc.)

note also that clojure itself is making it impossible right now to correctly sort by version, as they released beta1 > beta2 > RC1 > beta3 > beta4

the link to /CURRENT works again now

BTW the /CURRENT bit is optional now