ruby-build v20200518

[jasonkarns]

fixes #854 and closes #695

pulls ruby-build v20200401...v20200518

https://github.com/rbenv/ruby-build/compare/v20200401...v20200518 - **Add new option to exclude EoL'ed versions** - **Fix CI: Add `--list-exclude-eol` option to test** - **ruby-build: add short option "-d" alias to "--definitions"** - **rbenv-install: show the short list by default** - **Fix CI** - **-rc, -preview, -dev versions are also removed from short list** - **Fix CI** - **do not exclude warn_unsupported versions in short list** - **the short list now shows only latest stable versions** - **rename some functions to reflect more closely what it does** - **revert adding -d options alias for --definitions** - **skip cd in to DEFINITION_DIR in subshell** - **Reword s/Try/Use/** - **s/all built-in definitions/all available definitions/** - **s/all available definitions/all local definitions/** - **Update to OpenSSL 1.1.1f for Ruby 2.5+** - **mark ruby 2.5 to security maintenance** - **CVE-2020-1967, bump openssl to 1.1.1g** - **PR: #1419 should be applied also bin/rbenv-install** - **Add artichoke-dev to install the latest Artichoke nightly build** - **Replace one more "all available versions" with "all local versions"** - **ruby-build 20200518**

This is primarily https://github.com/rbenv/ruby-build/pull/1402

A couple distinctions:

• ruby-build only prints the latest of any non-mri engine. (that is, only truffleruby-24, not truffleruby-23 and -24 despite that they are each still non-eol)
• due to MRI's versioning scheme, minor versions of mri ruby are considered distinct

Both of these diverge from node-build's behavior:

• node-build will print the latest major of any engine (excluding EOLs and prereleases) so for example we'll include chakracore-8 and chakracore-10.
• further, minor versions of the primary nodejs engine are not considered distinct

These distinctions actually make node-build's implementation simpler because the filtering logic is consistent regardless of the engine.

[jasonkarns]

Calling attention of this to @asdf-vm folks (@augustobmoura, @HashNuke, @Stratus3D, @smorimoto)

I'm planning to release this in the coming week or so as a major version bump (v5). I can release a prerelease version if that would be beneficial. Though I suspect most consumers of node-build (both individuals and tools like asdf) don't have any means of version pinning so I doubt the prerelease nor major bump would have any practical effect.

FWIW, I also intend to switch to a hybrid semver+calver scheme soon. (something with a normal numeric major version but a calver ISO8601 YYYYMMDD for the minor or patch segment)

[jasonkarns]

Doing a bit of due-diligence, I went through the history of asdf-ruby around and shortly-after the time when ruby-build v20200518 was released. The intention being to see what (if any) changes were necessary to asdf-ruby as a result of that release. The assumption is that if asdf-ruby and asdf-nodejs are sufficiently similar, any changes that ruby-build v20200518 forced upon asdf-ruby, would likely be necessary for asdf-nodejs to do in response to this PR.

The only PR that seemed relevant was: https://github.com/asdf-vm/asdf-ruby/pull/153 which I wouldn't consider a blocker to this PR.