Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sort versions chronologically #134

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from
Open

Sort versions chronologically #134

wants to merge 2 commits into from

Conversation

ardislu
Copy link
Contributor

@ardislu ardislu commented Dec 8, 2022

Closes #133

@elopez
Copy link
Member

elopez commented Dec 12, 2022

I think sorting them numerically is nicer than purely alphabetical sort, but I'd be cautions on switching the order from newer -> older to older -> newer -- I think there's a few places that do things like solc-select versions | head -1 to grab the latest release number.

Ignore my previous concern, I'm not finding the script calls I thought we had on places 🤷 and worst case it should not take much to fix them.

@ardislu
Copy link
Contributor Author

ardislu commented Dec 13, 2022

Regarding ordering by older -> newer instead of newer -> older, I picked this ordering to match how nvm sorts. I checked some other tools and it looks like this is the prevailing convention:

rvm:

$ rvm list known
# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.7[-head] # security released on head
[ruby-]1.9.1[-p431]
[ruby-]1.9.2[-p330]
[ruby-]1.9.3[-p551]
[ruby-]2.0.0[-p648]
[ruby-]2.1[.10]
[ruby-]2.2[.10]
[ruby-]2.3[.8]
[ruby-]2.4[.10]
[ruby-]2.5[.8]
[ruby-]2.6[.6]
[ruby-]2.7[.2]
[ruby-]3[.0.0]

(...)

gvm:

$ gvm listall

gvm gos (available)

   go1
   go1.0.1
   go1.0.2
   go1.0.3
   go1.1
   go1.1rc2
   go1.1rc3
   go1.1.1
   go1.1.2
   go1.2
   go1.2rc2
   go1.2rc3
   go1.2rc4
   go1.2rc5
   go1.2.1
   go1.2.2
   go1.3
   go1.3beta1
   go1.3beta2
   go1.3rc1
   go1.3rc2
   go1.3.1
   go1.3.2
   go1.3.3
   go1.4
   go1.4beta1
   go1.4rc1
   go1.4rc2
   go1.4.1
   go1.4.2
   go1.4.3
   go1.5

(...)

Also note that solc-select versions | head -1 would not output the latest release using the current sort either, for example if I have all ^0.8.0 versions installed then solc-select versions currently outputs:

$ solc-select versions
0.8.9
0.8.8
0.8.7
0.8.6
0.8.5
0.8.4
0.8.3
0.8.2
0.8.17 (current, set by /home/ubuntu/.solc-select/global-version)
0.8.16
0.8.15
0.8.14
0.8.13
0.8.12
0.8.11
0.8.10
0.8.1
0.8.0

So it would not output the latest version:

$ solc-select versions | head -1
0.8.9

This gave me another idea though. It would be really useful for solc-select install and solc-select use to accept the argument latest as an alias for the latest Solidity version (similar to how solc-select install all can be used as an alias to install all versions). I created #138 to track this idea.

@ardislu
Copy link
Contributor Author

ardislu commented Dec 19, 2022

Rebased the commit against the latest updates in dev, and also amended to sort get_installable_versions():

-           for version in get_installable_versions():
+           for version in sorted(get_installable_versions(), key=lambda v: [int(s) for s in v.split(".")]):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sort versions chronologically instead of alphabetically
2 participants