Use the HEAD of ruby-build instead of a release tag

[dazuma]

In a discussion with the maintainers of ruby-build, it appears they do not intend to update the release tag for every new version added. In particular, support for MRI 2.5.5 was added to master 4 days ago; however, the maintainers are choosing not to cut a release with this update for now. As a result, asdf is still missing support for Ruby 2.5.5, and there does not seem to be a path forward.

To address this, as well as future occurrences where asdf-ruby might be left behind, it might make sense to modify utils.sh to pull the HEAD of ruby-build master instead of a release tag. (This would also prevent delays if the maintainers of asdf-ruby are away when a tag update is needed.)

[Stratus3D]

By using a specific tag in asdf-ruby we can control the version of ruby-build we use. And we only have to upgrade when we choose to. If a new version of ruby-build breaks something in asdf-ruby we can keep using an older version of ruby-build if we need to. Another downside to always upgrading to master means we might not know which version of ruby-build a user has when they report an issue. Overall I think it's safer to be explicit about dependency versions.

I think the issue here is that a new ruby-build version must be tagged before the latest version of Ruby is available. Even though the Ruby source code is already available and the release of a new Ruby version typically requires no changes to ruby-build itself, other than adding the new version file (https://github.com/rbenv/ruby-build/tree/master/share/ruby-build). In short, I think this is really an issue that should be addressed on the ruby-build side of things. There is nothing preventing ruby-build from always pulling Ruby versions from a list that is always updated.

How does rbenv handle this? It relies on ruby-build.

[dazuma]

We've had the conversation on the ruby-build side of things. As I understand it, ruby-build's release tags are pretty much being used only for integrations with other tools (like asdf and homebrew) that the ruby-build maintainers don't want to take responsibility for. Especially since they have such rapid updates on ruby-build (across 4+ active Ruby implementations), they're not willing to cut releases every time, and have to take responsibility for all those releases being dependencies. Even adding MRI 2.5.5 was not considered significant enough to cut a ruby-build release. (I'm not saying I agree; I'm just relaying the message from the ruby-build maintainers.)

IIRC rbenv pulls ruby-build from master (although someone should verify that, as my info is fuzzy and a bit dated). But if that is the case, it would seem reasonable for asdf-ruby to do likewise.

[dazuma]

I get that there are trade-offs here, but it seems like asdf's architecture has already made a choice on this. Doesn't asdf plugin-update just pull the plugin from HEAD? At which point, we've already punted on tool version. And in both cases, if we're really concerned about identifying what "version" was being run, there's always the SHA.

[amalrik]

What about include an optional parameter lets say:
asdf install ruby 2.5.5 --use-head
or
asdf install ruby 2.5.5 --head

This flag would permit using the HEAD of ruby-build.
I know this solution is far from perfect. But could be an interesting compromise.

[Stratus3D]

We are eventually going to be tagging asdf plugins, and by default only using the latest tag instead of using master (asdf-vm/asdf#166). We are just short on resources and haven't had time to make the changes for that.

There is SHA, but without a trivial way of viewing it many users won't provide it when reporting bugs. Ideally asdf plugin-list should return plugin versions (or the SHA) so the user can report it.

To me it seems like the issue causing this problem lies in the way ruby-build is designed. The availability of new Rubies shouldn't require a code change. If ruby-build could pull from an up to date list of Rubies and the needed build options we wouldn't need to be concerned about the tagging situation in ruby-build or asdf-ruby. I assume rbenv and ruby-build are maintained by the same group of devs, so they are willing to risk using master since they are the ones in control of it.

[Stratus3D]

Closing this because I've merged #115. I think using a specific commit instead of HEAD is a good compromise here until things get sorted out with ruby-build.