Closed kien-truong closed 10 months ago
we sort these using the rust semver
crate which isn't handling this version correctly.
looking at the output of rtx ls-remote java
I really don't know if we'll ever be able to properly sort everything in there unfortunately. A lot of java runtimes just behave really strangely.
What I find odds is sometimes it sorts correctly, for example
temurin-11.0.14+9
temurin-11.0.14+101
Also, I think temurin-17.0.8+101
is actually version 17.0.8.1+1
, which somehow got converted into 17.0.8+101
I think what needs to happen is 2 things:
As far as what the override function could be, I'm not really sure how best to use the PartialOrd trait here but maybe we could just start with this:
fn partial_cmp(a: &str, b: &str) -> Option<std::cmp::Ordering>
If someone wanted to write that function even just for temurin, it could just be a simple playground script that I can work to integrate in the codebase.
I think I managed to resolve this actually without needing to do what I mentioned before. Now rtx uses https://rtx-versions.jdx.dev/java for the versions which I pipe through sort -V
and I think it sorts it correctly:
$ rtx ls-remote java | grep temurin-11
temurin-11.0.12+7
temurin-11.0.13+8
temurin-11.0.14+9
temurin-11.0.14+101
temurin-11.0.15+10
temurin-11.0.16+8
temurin-11.0.16+101
temurin-11.0.17+8
temurin-11.0.18+10
temurin-11.0.19+7
temurin-11.0.20+8
temurin-11.0.20+101
temurin-11.0.21+9
Describe the bug Java Temurin-17 is having a newer version that appears before an older version.
Expected behavior The versions should be in correct order
rtx doctor
output