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!

[jthegedus]

Most plugins aren't being released with tags. My initial idea was to translate the tag into the SHA leveraging the existing SHA support and circumventing the issues @thbar raises.

GitHub Actions guidelines are silly, everyone should be using SHAs. GitHub should really be supporting an immutable tags solution.

[thbar]

I prefer SHA but also must say that tags are helpful to bring security fixes automatically to teams without the bandwidth or the will to maintain SHA freezing!

In the case of asdf plugins though, definitely agree, the ones I use never issue a release nor a tag, so this is a very good point.

[jthegedus]

bring security fixes automatically

This would still require a user to reinstall or update the plugin on their machine to pull the latest tag. Just because a new semver minor version is published does not mean the user gets the latest changes in their code. The frequency with which we update dependencies and do full installs in our software, especially on the web, has given us a false sense of security.

Additionally, if we were to support tags at all, it would be pinning to specific versions and not version ranges.

[jthegedus]

bring security fixes automatically

This would still require a user to reinstall or update the plugin on their machine to pull the latest tag. Just because a new semver minor version is published does not mean the user gets the latest changes in their code. The frequency with which we update dependencies and do full installs in our software, especially on the web, has given us a false sense of security.

Additionally, if we were to support tags at all, it would be pinning to specific versions and not version ranges.

Keep the suggestions and discussions coming, and feel free to submit a solution via PR should anyone have the time.

[thbar]

This would still require a user to reinstall or update the plugin on their machine to pull the latest tag

Very true for users, yet I know that people use asdf in automated builds (CI, auto-deploy etc).

[jthegedus]

In all cases using pinned SHA versions more consistent than version ranges. CI and local machine using a different version from the same config file should be considered a bug, not a feature.

[jthegedus]

As an update, plugins do support updating to a specific branch or git tag:

From asdf help:

asdf plugin update <name> [<git-ref>]   Update a plugin to latest commit on
                                        default branch or a particular git-ref

Used as:

asdf plugin add firebase https://github.com/jthegedus/asdf-firebase
# update to specific tag
asdf plugin update firebase v1.1.0
# or with a sha
asdf plugin update firebase 57f29ec

#1204 will make this easier, requiring a single step.

[aabouzaid]

Since it looks like there is no solution provided so far in asdf itself, I've created a plugin called asdf-plugin-manager to fix that issue and to manage asdf plugins securely and declaratively.

# .plugin-versions
golang     https://github.com/asdf-community/asdf-golang.git     d8dec15
terraform  https://github.com/asdf-community/asdf-hashicorp.git  c048526

# Add all plugins according to .plugin-versions file
asdf-plugin-manager add-all

Or

# Add named plugin according to .plugin-versions file
asdf-plugin-manager add terraform

[jfly]

For the record, mise invented this .mise.toml file to solve this problem.

Sure would be cool if these two ecosystems could agree upon a standard ;)