Support for upgrading outdated versions

[vraravam]

This is more of a feature request. If/when issue #240 is completed, we can add support for querying the list-all functionality for that plugin, and then compare with the versions of the language that is currently installed/applicable in the current folder. This can be exposed via asdf outdated [plugin-name].

[Stratus3D]

I'm open to contributions for this command, but I'm not sure when it would be used. asdf should work fine even when installed versions are no longer available via the plugin. And right now this functionality could be achieved with a simple shell script. All you'd need to do is capture the output of asdf list-all <tool> and asdf list <tool> and find the versions only present in the asdf list command.

This also doesn't depend on #240.

[vraravam]

@Stratus3D - Do you think there's a difference in upgrade vs update in the context of asdf. IF so, then I agree that this could be construed to be different from #240. I have reworded this request title - in case it clarifies the intent.
Also, I was looking for a way to update to the latest version allowed by semantic versioning rules (not the inclusive vs exclusive, ~, etc) - but more in the context of "what has the user tried to lock based on the .tool-versions file, and for that, in the case of non-standard plugins, was where I was thinking that #240 is actually a dependency.
As an example, if the .tool-versions file has ruby locked to 2.5, and the plugin's list-all functionality lists 2.5.1, my feature request can then update from 2.5.0 (which is installed) to 2.5.1 which is now available. Hope that makes it clearer?

[Stratus3D]

In that case I think this goes along with #352. We don't want asdf to have to be concerned with versioning schemes. See my comment on that issue for the reasons why: #352 (comment). If this is functionality that's needed it will need to be handled by the plugin, since it's the plugin's responsibility to deal with comparison and manipulation of tool versions.

[vraravam]

Thanks @Stratus3D - yes, i think #352 is very close to what I was thinking. I'll close this ticket.