[hsbt]

ruby-version: mswin installs the ruby-loco master build, which has not been updated since 2026-10-14 because its mswin workflow fails every day. #969 removes mingw for the same kind of reason.

I publish mswin builds at https://cache.ruby-lang.org/pub/ruby/binaries/mswin64/ for stable releases and for master daily, and I will keep maintaining them. This adds mswin as an engine with 3.4 to 4.0 and head, and points mswin at the new master build. The default Windows builds stay RubyInstaller.

- uses: ruby/setup-ruby@v1
  with:
    ruby-version: mswin-4.0 # or mswin-head, mswin

SSL_CERT_FILE is set to Git's CA bundle for mswin, because the OpenSSL in these builds has no usable trust anchors on the runners.

I think plain mswin should mean the latest stable release like ruby and jruby, and I'd like to change that in a follow-up if you agree.

Generated with Claude Code

[ntkme]

I wonder if it will be better to make a breaking change and have mswin points to latest stable release just like ruby points to latest stable release if we are adding mswin-head.

[hsbt]

I agree. As it is a breaking change, I'd like to hear from @eregon before changing it in this PR.

[eregon]

This is quite error-prone as engine === 'ruby' has always been used and might be in the future.
Not sure what's a good solution though.

[ntkme]

Another approach I can think of that is potentially less error-prone is to make this more object oriented. E.g. introduce a class RubyVersion. If we only pass the object around, and only call the instance method provided by the class, so there is less chance to have errors?

class RubyVersion {
  constructor(rubyVersion) {
    ...
  }
  get engine() {
    ...
  }
  get isCRuby() {
    ...
  }
  get version() {
    ...
  }
  get floatVersion() {
    ...
  }
}

[eregon]

I'll think a bit about this.

I agree if we add those names that it would be natural for mswin to be the last release (because mswin becomes an engine, it was a version before).
It's not great that we'd change the meaning of mswin though, both in what version it resolves though and where it pulls builds from, users might not expect that.
There are rather few public usages.

I would like to know more about the longer-term plans for those builds.
For example it seems https://www.ruby-lang.org/en/documentation/installation/ doesn't mention them.
Is the goal they become the recommended way to install on Windows?
To always keep 2 options with RubyInstaller & these builds?
What would be the advantages of using these builds over RubyInstaller which is the best-established builds on Windows?

I'm unsure it's worth having 2 variants of builds on Windows.

[eregon]

mswin isn't really an interpreter so this reads a bit strange.

[eregon]

Relevant ticket: https://bugs.ruby-lang.org/issues/22180