Closed egawata closed 1 year ago
This PR changes the way of sorting by version in
listall
. As a problem is reported at #305,-V
option isn't available withsort
on MacOS, andlistall
doesn't work correctly. By this PR, go versions are sorted correctly both on Linux and MacOS.There's also another advantage. In the current method, the first minor version comes first, then beta, rc followed by the patch versions at the end.
go1.11 go1.11beta1 go1.11beta2 go1.11beta3 go1.11rc1 go1.11rc2 go1.11.1 go1.11.2 go1.11.3 go1.11.4
In the method of this PR, betas and rcs comes last. I think this is easier to see.
go1.11 go1.11.1 go1.11.2 go1.11.3 go1.11.4 go1.11beta1 go1.11beta2 go1.11beta3 go1.11rc1 go1.11rc2
Also, release versions are sorted naturally.
I don't think so. go1.11beta1
version should be behind go.1.11
version. because go1.11beta1
, go1.11beta2
, go1.11beta3
are the beta version for the `go1.11
. @egawata what do you think about it?
@keonjeo
Thank you for your comment. 😄
I agree with you. What I meant is that it would be better to group them to regular, beta and rc versions.
Of course, it would be better to be ordered properly(beta, rc and regular ones). But it isn't the main purpose of this PR. I want to solve a problem that we failed to run listall
on macos.
This PR changes the way of sorting by version in
listall
. As a problem is reported at #305,-V
option isn't available withsort
on MacOS, andlistall
doesn't work correctly. By this PR, go versions are sorted correctly both on Linux and MacOS.There's also another advantage. In the current method, the first minor version comes first, then beta, rc followed by the patch versions at the end.
In the method of this PR, betas and rcs comes last. I think this is easier to see.
Also, release versions are sorted naturally.