Skip to content

Conversation

@jasonkarns
Copy link
Member

@jasonkarns jasonkarns commented May 12, 2024

fixes #854 and closes #695

pulls ruby-build v20200401...v20200518

rbenv/ruby-build@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 rbenv/ruby-build#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.

metalefty and others added 29 commits January 30, 2020 14:57
when showing available versions
As suggested by @eregon, now we have "-l/--list" option for the short list of versions. Behaviour of `ruby-build --definitions` is kept as before for compatibility. rbenv-install: -L/--list-all full list -l/--list short list ruby-build: -d/--definitions full list -l/--list short list
it is not actually EoL'ed. `warn_unsupported` indicates that the versions are nearing EoL.
for each Ruby implementations like the following. 2.4.9 2.5.7 2.6.5 2.7.0 jruby-9.2.9.0 maglev-1.0.0 mruby-2.1.0 rbx-3.107 truffleruby-19.3.1
This is out of scope of this PR.
as it is not necessary. Pointed out by @mislav in review.
Suggested by mislav: rbenv/ruby-build#1402 (comment) > I wonder should we substitute "built-in" with something like "all > available definitions". Since ruby-build will additionally pick up > definitions found under the paths listed in RUBY_BUILD_DEFINITIONS, > these definitions will get listed even if they are not "built-in". > Therefore, "built-in" feels like a misnomer here.
"available" implies ruby-build will be checking online sources but actually ruby-build doesn't do that. "local definitions" may be prefered. Pointed out by jasonkarns.
Update to OpenSSL 1.1.1f for Ruby 2.5+
s/all built-in definitions/all local definitions/
Add artichoke-dev to install the latest Artichoke nightly build
The list `rbenv install -l` is too long, show latest stable releases by default
@jasonkarns jasonkarns changed the title ruby build upstream ruby-build v20200518 May 12, 2024
@jasonkarns jasonkarns force-pushed the ruby-build-upstream branch 2 times, most recently from 11a99cb to 13c84de Compare May 24, 2024 14:31
ruby-build 20200518 * ruby-build: add short option "-d" alias to "--definitions" * rbenv-install: show the short list by default As suggested by @eregon, now we have "-l/--list" option for the short list of versions. Behaviour of `ruby-build --definitions` is kept as before for compatibility. rbenv-install: -L/--list-all full list -l/--list short list ruby-build: -d/--definitions full list -l/--list short list The short list now shows only latest stable versions for each Ruby implementations like the following: 2.5.8 2.6.6 2.7.1 jruby-9.2.11.1 maglev-1.0.0 mruby-2.1.0 rbx-4.15 truffleruby-20.0.0 * 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 Allow to install the latest official Artichoke nightly build from https://github.com/artichoke/nightly/releases * tag 'refs/rbenv-tags/v20200518': ruby-build 20200518 Replace one more "all available versions" with "all local versions" Add artichoke-dev to install the latest Artichoke nightly build PR: #1419 should be applied also bin/rbenv-install CVE-2020-1967, bump openssl to 1.1.1g mark ruby 2.5 to security maintenance Update to OpenSSL 1.1.1f for Ruby 2.5+ s/all available definitions/all local definitions/ s/all built-in definitions/all available definitions/ Reword s/Try/Use/ skip cd in to DEFINITION_DIR in subshell revert adding -d options alias for --definitions rename some functions to reflect more closely what it does the short list now shows only latest stable versions do not exclude warn_unsupported versions in short list Fix CI -rc, -preview, -dev versions are also removed from short list Fix CI rbenv-install: show the short list by default ruby-build: add short option "-d" alias to "--definitions" Fix CI: Add `--list-exclude-eol` option to test Add new option to exclude EoL'ed versions
@jasonkarns jasonkarns force-pushed the ruby-build-upstream branch from 13c84de to 18ef6cf Compare May 24, 2024 14:37
- we don't need to worry about p* patches like Ruby - we also don't treat minor version as "distinct" like Ruby does (ruby-build wants to list 3.0, 3.1 and 3.2 as distinct, we only care about majors)
@jasonkarns jasonkarns force-pushed the ruby-build-upstream branch from 18ef6cf to 78453e6 Compare May 24, 2024 20:38
@jasonkarns jasonkarns marked this pull request as ready for review May 24, 2024 21:08
@jasonkarns
Copy link
Member Author

jasonkarns commented May 24, 2024

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
Copy link
Member Author

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: asdf-vm/asdf-ruby#153 which I wouldn't consider a blocker to this PR.

@jasonkarns jasonkarns added this to the v5 milestone May 27, 2024
@jasonkarns jasonkarns merged commit 20a756d into main May 29, 2024
@jasonkarns jasonkarns deleted the ruby-build-upstream branch May 29, 2024 14:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

7 participants