Open momiji opened 2 months ago
asdf
is just a framework. If you don't like how the java plugin works, you might be better served by directing your comments to its authors:
asdf plugin list --urls | grep java
Regarding "what is the latest java?", try instead:
asdf latest java openjdk
openjdk-23-loom+2-48
asdf
provides everything you need to track your distribution:
asdf list all java | grep ^openjdk | tail -5
openjdk-21.0.1 openjdk-21.0.2 openjdk-22 openjdk-22.0.1 openjdk-23-loom+2-48
But by all means, submit a PR.
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