You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
asdf latest is broken and useless
Describe the proposed solution
I wonder if there was already a solution to this annoying issue and came up with some ideas.
My example:
$ asdf current java
java openjdk-21.0.2 /home/flops/.tool-versions
$ asdf latest java
No compatible versions available (java [0-9])
$ asdf latest --all
java zulu-musl-22.30.13 missing
One can immediately figure some issues:
latest java should not reply with no version, but should report the latest openjdk 21 version
latest --all should not reply with the latest of all java versions
Once the difference between the 2 is fixed, I have several proposal for managing variants and versions.
This does introduce no breaking change, which is I guess very very important.
1. Variants - The openjdk-21 issue
The idea is to ask java and other plugins developers to add a new variants file containing a list if regex if all their applications.
For example, for the java plugin, this file could contain a line with openjdk-21. and another with zulu-musl-22., etc. The idea is to list all "modules" provided by the plugin.
This way, asdf can identify I have installed openjdk-21 (and not 20 neither 22) and should list updates for this one only.
And of course, if I installed both zulu and openjdk, then propose both updates :)
We could then get something like this, if I installed both openjdk 21 and 22:
I was thinking that it could be interesting to be able to allow updating 1.x versions without updating to 2.x if I want to stay to 1.x.
There is no "good" way for doing this. I was first thinking that may adding a new file for partial versions and so on, but it looks like to be too overkill. Then I considered an easier solution, just propose all matching updates and let the user choose what he wants.
The idea is then to have something like this:
$ asdf latest xxx
xxx 2.5.1 missing (latest)
xxx 1.8.0 missing (latest 1.* based on installed 1.7.1)
xxx 1.7.5 missing (latest 1.7.* based on installed 1.7.1)
Here, as I have installed version 1.7.1, update lists the latest "1.7.", "1." and "*".
3. Pre-release - Alpha/Beta/...
There should be a way to prevent updating to a pre-release.
One idea is to mark them in the versions list provided by the plugins, maybe with a "*" or anything alike.
Maybe it is already the case?
This way, it is still possible to install a beta version, but not to update to it automatically.
Requirements
The only requirements for thes ideas to work are:
the version separator must be "." - this is probably already the case for every software
the versions provided by the plugin (I couldn't find how this is done yet) MUST be sorted by version (and not alphabetically), it seems evident but we must not forget it
the variants file does not need to be sorted, unless I missed something
Conclusion
These are just ideas that seem to be reasonable enough (at least to me) to add more value to asdf, especially as it does not introduce any breaking change ;)
Of course, there are probably a lot of work to do on asdf side to implement such features, and then have the plugins add the necessary files to provide the variants prefixes.
Let's continue the discussion here!
Describe similar asdf features and why they are not sufficient
None
Describe other workarounds you've considered
None
The text was updated successfully, but these errors were encountered:
latest has no meaning when the plugin in question has many different sources openjdk, zulu etc. That specific plugin requires you to always provide a filter to the query.
asdf latest --all will iterate through your installed plugins and call asdf latest <plugin> and tell you if you have the listed version installed. So it's behaviour here is different, likely just doing asdf list all java and getting the last version.
I agree, the error is obtuse, but not sure if it should be fixed here or in the plugin
Is your feature request related to a problem? Please describe
asdf latest is broken and useless
Describe the proposed solution
I wonder if there was already a solution to this annoying issue and came up with some ideas.
My example:
One can immediately figure some issues:
latest java
should not reply with no version, but should report the latest openjdk 21 versionlatest --all
should not reply with the latest of all java versionsOnce the difference between the 2 is fixed, I have several proposal for managing variants and versions.
This does introduce no breaking change, which is I guess very very important.
1. Variants - The
openjdk-21
issueThe idea is to ask java and other plugins developers to add a new variants file containing a list if regex if all their applications.
For example, for the java plugin, this file could contain a line with
openjdk-21.
and another withzulu-musl-22.
, etc. The idea is to list all "modules" provided by the plugin.This way, asdf can identify I have installed openjdk-21 (and not 20 neither 22) and should list updates for this one only.
And of course, if I installed both zulu and openjdk, then propose both updates :)
We could then get something like this, if I installed both openjdk 21 and 22:
2. Versions - Sticking to 1.x
I was thinking that it could be interesting to be able to allow updating 1.x versions without updating to 2.x if I want to stay to 1.x.
There is no "good" way for doing this. I was first thinking that may adding a new file for partial versions and so on, but it looks like to be too overkill. Then I considered an easier solution, just propose all matching updates and let the user choose what he wants.
The idea is then to have something like this:
Here, as I have installed version 1.7.1, update lists the latest "1.7.", "1." and "*".
3. Pre-release - Alpha/Beta/...
There should be a way to prevent updating to a pre-release.
One idea is to mark them in the versions list provided by the plugins, maybe with a "*" or anything alike.
Maybe it is already the case?
This way, it is still possible to install a beta version, but not to update to it automatically.
Requirements
The only requirements for thes ideas to work are:
Conclusion
These are just ideas that seem to be reasonable enough (at least to me) to add more value to asdf, especially as it does not introduce any breaking change ;)
Of course, there are probably a lot of work to do on asdf side to implement such features, and then have the plugins add the necessary files to provide the variants prefixes.
Let's continue the discussion here!
Describe similar
asdf
features and why they are not sufficientNone
Describe other workarounds you've considered
None
The text was updated successfully, but these errors were encountered: