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

Better version management #1751

Open
momiji opened this issue May 2, 2024 · 0 comments
Open

Better version management #1751

momiji opened this issue May 2, 2024 · 0 comments

Comments

@momiji
Copy link

momiji commented May 2, 2024

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:

$ asdf latest --all
java    openjdk-21.0.3      missing
java    openjdk-22.0.1      missing

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:

$ 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

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

No branches or pull requests

1 participant