[hsbt]

ruby-version: mswin installs the mswin build of ruby-loco, which has not been updated since 2026-10-14 (see #972). The stale build already gets in the way: rb_len_t landed in master in November, and nobu's PRs updating ruby/openssl, ruby/date and ruby/zlib for it cannot be tested on mswin, because their CI still gets the October build.

This PR keeps mswin as the master build and only changes where it comes from: the daily builds at https://cache.ruby-lang.org/pub/ruby/binaries/mswin64/, which I maintain as the official mswin builds of https://bugs.ruby-lang.org/issues/22180. The latest one is picked from index.json at runtime, and arm64 is available too. As larskanis noted in #972, mswin has always been a development build, so the switch needs no deprecation period. The download token is now sent only to github.com, so it does not reach cache.ruby-lang.org.

Release versions such as mswin-4.0 are left for a separate PR.

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

[hsbt]

I narrowed this PR to switching where mswin comes from, since it is stuck on the 2026-10-14 master and blocks testing the rb_len_t changes on mswin. It leaves mingw, ucrt and the future of ruby-loco in #972 untouched, and release versions are no longer part of it.

[hsbt]

@ntkme Thanks for the commits you pushed here. They are kept on a branch for the follow-up PR with the release versions, where I'll also consider your RubyVersion idea.