prepare for Ruby 3.2 support

[flavorjones]

This issue is a placeholder for a conversation about Ruby 3.2 support.

This year, I'd like to be able to cut a release of rake-compiler-dock shortly after Ruby 3.2 final is released.

To that end, I'd also like us to consider shipping a "release candidate" of rake-compiler-dock for downstream users to test with and give feedback on.

@MSP-Greg, do you expect any Windows-specific challenges for this release? I'm looking at https://github.com/MSP-Greg/ruby-loco/releases and it looks like we may need to support ucrt, mswin, and mingw? Are there documents you can point me at so I can build more context?

[MSP-Greg]

do you expect any Windows-specific challenges for this release

Not sure about Rust gems. Otherwise, I don't think I've needed to make any major changes to ruby-loco in quite a while.

we may need to support ucrt, mswin, and mingw?

Not sure, up to you. The only popular public Windows release will be RubyInstaller2's ucrt build. @larskanis ?

But, there are people using mswin builds, I quickly threw up https://github.com/MSP-Greg/ruby-mswin/releases, and will probably try to keep mswin builds available. As to mingw, not sure, I suspect most people have switched to ucrt, but ruby/ruby runs CI against all three (ucrt, mswin, and mingw) in master...

A few years ago, it was very difficult to build ext gems with mswin. Now, Microsoft/vcpkg has a lot of packages available.

RubyInstaller2 builds have ridk enable to set the env for the MSYS2 build tools (mingw or ucrt). When using mswin, the user needs to enable the msvc builds tools. As you've probably seen, using setup-ruby in Actions does that in its code. That has confused a few people trying to do things locally.

I haven't worked that much with rake-compiler-dock, but I do have all the build tools installed locally, both Windows & WSL2/Ubuntu...

[larskanis]

do you expect any Windows-specific challenges for this release?

There is one bigger change in RubyInstaller-3.2, which is OpenSSL-3.0. It's changes pass through to the Ruby API, which makes it partly incompatible and requires such patches. However this change to RubyInstaller doesn't change anything to RCD, since we don't provide any libraries for bundling into binary gems.

it looks like we may need to support ucrt, mswin, and mingw?

RCD already supports mingw only for ruby up to 3.0 and ucrt for 3.1. Ruby master is no longer tested on mingw - only ucrt and mswin. I personally have no interest on supporting mswin in RubyInstaller or RCD. So also no changes from my POV.

The issues I'd like to have fixed are:

• move away from manylinux: Use manylinux Docker image for aarch64-linux #68 (comment)
• Add Rust support RCD 🤝 Rust (my experience) #74
• Improve support of older linux-aarch64 [install] ruby:2.7.4-slim-buster Docker image on Apple Silicon sparklemotion/nokogiri#2500
• Add support for linux-musl consider supporting *-linux-musl as a target platform #75

All the above are unrelated to the particular ruby-3.2 release, but I often used to do such changes when adding a new ruby release.

[MSP-Greg]

it looks like we may need to support ucrt, mswin, and mingw?
Ruby master is no longer tested on mingw

Thanks for pointing that out, I wasn't aware of that. Happened about 3 weeks ago...

Re OpenSSL 3, I recently noticed that you were building head with it. As we get closer, setup-ruby will need to grab the package. I suppose that could be done now for the Ruby head build. Haven't seen any indication of when MSYS2 will be changing to OpenSSL 3, have you? MSFT's vcpkg already has...

[ianks]

Another big request I have is to add linux/arm64 Docker images. Currently, building on M1 is unbearably slow in many cases due to the virtualization overhead. I’ve almost given up on running RCD locally as a result.

[flavorjones]

See #82 which is a naive first pass at 3.2 support.

[flavorjones]

3.2 support is merged in #82 and #83. I'm going to close this since 3.2 was the intent of this issue; but obviously we should try to get some of the other things listed in here in the next version.