IronRuby 4.0.5

IronRuby 4.0.5 is the first release built for .NET 10 and .NET 11, and the first without .NET 8. .NET 8 reached the end of Microsoft support on 10 November 2026, and 4.0.4 was the last release for it. Each download now comes in two builds: one on .NET 10, an LTS release and the default download, which keeps the names earlier releases used, and one on .NET 11, named -net11-. Both carry their runtime, so neither needs .NET installed. On .NET 11.0.0, multiplying and dividing big Integers is several times slower than on .NET 10; most other code runs a few percent faster there. Apart from the move to the new runtimes, it has one fix, which .NET 11 made necessary: an Integer too large for .NET's BigInteger raises NoMemoryError on every runtime.

.NET 10 and .NET 11

• .NET 8 is gone. The source builds for net10.0 and net11.0
  (IronRubyTargetFrameworks in Directory.Build.props), and the code that only .NET 8
  needed is removed (#198). A program that hosts IronRuby, or loads its assemblies, needs
  .NET 10 or later. Scripts run with the self-contained downloads are not affected: the
  downloads bring their own runtime.
• Two downloads for each platform. The archives named as before,
  ironruby-4.0.5-<platform>, and the Windows installer are built on .NET 10 and carry the
  .NET 10 runtime. .NET 10 is supported until 14 November 2028
  (.NET support policy).
  The ironruby-4.0.5-net11-<platform> archives are the same IronRuby built on .NET 11
  and carry its runtime. Their launchers run the .NET 11 build. There is no .NET 11
  installer.
• Why .NET 10 is the default. On .NET 11.0.0, BigInteger multiplication and division
  are 3 to 6 times slower than on .NET 10, in plain C# too: a 3,000-digit a * b takes
  176 µs instead of 37 µs. Code that works on big Integers runs slower on the .NET 11
  download; TruffleRuby's pidigits benchmark takes 3.3 times as long (#198).
• Elsewhere, .NET 11 is a little faster (#198, Release builds measured side by side on
  Linux x64). Startup is about 5% shorter: ir -e 1 takes 430 ms instead of 456 ms, and
  require "json" 502 ms instead of 530 ms. TruffleRuby's bench/ (136 benchmarks) runs
  3.5% faster by geometric mean, and a 10-benchmark subset of ruby-bench 3.9% faster.
  AWFY is unchanged (+0.2%). Among the issue #89 micro-benchmarks, a raise rescued in
  place is 15% faster and Thread.new { }.join 17% faster, while is_a? is 25% slower.

Changed

• No Integer can be wider than about 2**31 bits (#198). .NET's BigInteger holds at
  most 2**31 - 64 bits on .NET 9 and later. The 4.0.4 downloads ran on .NET 8, where
  1 << 2**31 built the Integer; on the 4.0.5 downloads it raises NoMemoryError, as
  CRuby does when an allocation fails.
• On Windows, zlib runs on .NET 10's or .NET 11's zlib-ng (#198), the zlib inside
  .NET, where 4.0.4 ran on .NET 8's fork of zlib 1.2. Zlib::ZLIB_VERSION is
  "1.3.1.zlib-ng" instead of "1.2.13", and compressed bytes may differ from 4.0.4's.
  They inflate the same.

Fixed

• Too-large Integers on .NET 11 raise NoMemoryError (#198). .NET 11's BigInteger
  shifts no longer check its maximum length, while its other operations still do
  (dotnet/runtime#137327). So on .NET 11
  1 << 2**31 succeeded, and the next operation on the result, such as x | 1, raised a
  raw System::OverflowException. IronRuby now checks the limit itself, in left shifts,
  Integer#**, right shifts by a negative count and on negative Integers, and raises
  NoMemoryError as it does on .NET 10.

For contributors

• CI tests .NET 11 on every pull request and push, and .NET 10 before a release (#198).
  ci.yml runs net11.0 only on pull requests and pushes. net10.0 runs as well on a pull
  request from a release/* branch, on a run by hand (workflow_dispatch, tfms input:
  both, net10.0 or net11.0) and in release.yml when a v* tag is pushed. There,
  ci.yml's whole test set runs on both frameworks, and nothing is published unless it
  passes.
• Util/package-release.sh takes the framework from IR_TFM (net10.0 by default). A
  net11.0 archive is named ironruby-<version>-net11-<rid>, and its launchers default to
  that build. release.yml packages every platform on both frameworks.
• The startup library (Util/aot) is built for both frameworks (#198). A Linux Release
  build now installs IronRuby.Startup.dll in the net10.0 and the net11.0 ReadyToRun
  host. Before, it built for neither.
• ir.sh, ironruby(.cmd), the Makefile, default.mspec and the Util scripts default to
  net10.0; IR_TFM=net11.0 picks the .NET 11 build.

Download

Self-contained: unpack one and run ./ironruby, ./iirb.sh and ./igem.sh - on Windows
ironruby.cmd, iirb.cmd and igem.cmd. No .NET to install. Or, on Windows, run the
installer.

On .NET 10 (LTS, the default):

• Windows x64 installer: ironruby-4.0.5-win-x64-setup.exe, the zip below, installed
  into C:\IronRuby40-x64 and put on the PATH
• Windows x64: ironruby-4.0.5-win-x64.zip, with Windows Forms, WPF, ironrubyw.exe
  and Samples\Notepad\notepad.cmd
• Linux x64: ironruby-4.0.5-linux-x64.tar.gz
• macOS arm64: ironruby-4.0.5-osx-arm64.tar.gz, built in CI, not tested there

On .NET 11:

• Windows x64: ironruby-4.0.5-net11-win-x64.zip, with the same contents as the
  .NET 10 zip
• Linux x64: ironruby-4.0.5-net11-linux-x64.tar.gz
• macOS arm64: ironruby-4.0.5-net11-osx-arm64.tar.gz, built in CI, not tested there

SHA256SUMS lists the checksums of all of them. Each file and SHA256SUMS has a signed
build provenance attestation, which says which workflow built it, from which commit, in
which run:

gh attestation verify ironruby-4.0.5-net11-linux-x64.tar.gz --repo Largo/ironruby

What's Changed

• Drop .NET 8, add .NET 11 by @Largo in #198
• Release 4.0.5 by @Largo in #199
• Release workflow: publish only the archives; retry the flaky macOS publish by @Largo in #200

Full Changelog: v4.0.4...v4.0.5