Versioning of plugins

[rmoriz]

Please consider adding functionality to install a specific version/to update to a specific version of a plugin. Also please consider versioning/tagging plugins in their repos.

The recent changes in the nodejes plugin broke a lot of setups.

[Stratus3D]

@rmoriz good idea. I had thought about this before but decided it wasn't high priority since I hadn't heard any complaints. This is the first I've heard about it causing a problem, sorry about the trouble.

This will require a rewrite of the plugin install and plugin update commands, but it's definitely something we need to do. We will also need to tag all the plugins before making this change to asdf.

[vic]

I guess the easiest change would be to allow plugin-add to take a git branch/ref name (default to master) and use that when cloning the plugin.

[skotchpine]

Just did a patch for this. Clones plugin into <plugin-name>-<git-branch> instead of <plugin-name>.

[stephanos]

This would be a great addition! Just now the elixir plugin broke and we can only install the broken HEAD instead of a previous version. (see asdf-vm/asdf-elixir#90 for details)

[Stratus3D]

Questions:

• What commands should support plugin versions? asdf plugin-add is an obvious one, but it may be useful for other commands to take a plugin version argument too.
• When a plugin is added with a specific commit SHA as the version, how would plugin updates work?
• When a plugin is added with a specific branch as the version, how would plugin updates work?
• Should the plugin update command accept a version argument too?

[dvic]

My 2 cents.

What commands should support plugin versions? asdf plugin-add is an obvious one, but it may be useful for other commands to take a plugin version argument too.

I think just adding it to asdf plugin-addis sufficient (at least for my usecases).

When a plugin is added with a specific commit SHA as the version, how would plugin updates work?

It doesn't, it prints a info message maybe? (that the plugin can't be updated because it's pinned to a specific SHA commit)

When a plugin is added with a specific branch as the version, how would plugin updates work?

It simply checks if the branch (or tag) points to the same SHA commit, if not, it uses that SHA.

Should the plugin update command accept a version argument too?

If it's ok to "downgrade", then yes, it could be useful in situations like #90.

[jthegedus]

When a plugin is added with a specific commit SHA as the version, how would plugin updates work?

Only update to the latest sha for that branch - #800

When a plugin is added with a specific branch as the version, how would plugin updates work?

Only update to the latest sha for that branch - #800

Should the plugin update command accept a version argument too?

I have ideas for how we could support semver updates for plugin updates.

[J3m5]

Personally, I'd prefer to update to the last released tag or be able to select a tag.

[thbar]

Personally, I'd prefer to update to the last released tag or be able to select a tag.

Tags are convenient ; it would be nice to still always allow SHA too, because it provides a better way to ensure the target has not changed (a tag can be re-recreated, while a SHA does not), hence it is normally "more secure".

The GitHub Actions guidelines on versioning are interesting in that regard!