Build Ruby 3.0.0.preview1

[robotdana]

I'd like to use Ruby 3.0.0.preview1 with ruby/setup-ruby

It looks like this is all that needs doing in this repo?

[eregon]

I'm a bit hesitant to add previews and RCs to ruby/setup-ruby because:

• There are quite a few previews & releases, so it's extra work
• Previews are fairly unstable, the fact they are a fixed version might give the impression they are like releases, but actually they are only marginally more stable than ruby-head. The aim is to let people try new features and gather feedback, bugs are expected.
• There can be many breaking changes between a preview and the next release (e.g. Fiber scheduler & Ractor API is changing recently), so it often doesn't make too much sense to test in CI.
• AFAIK currently nobody is published builds of previews on Windows, and all recent Ruby versions should be available on all platforms listed in https://github.com/ruby/setup-ruby#supported-platforms

Is there a reason you want to use preview1 in CI instead of ruby-head?

[robotdana]

my reasoning for preferring this to head was that i can have confidence that each build of ci should pass unless something i did myself in my branch broke something. without a fixed version to test against i can’t be as sure a failure is my fault

but all of your points are fair so i can do with head if necessary

[eregon]

I see.
I think the main purpose of testing against -preview or -head is to try to ensure the software will work on the next Ruby release.
For that, I think testing against ruby-head is more useful, even though it keeps changing and might have occasionally regressions which are fixed later. Note that ruby-head from ruby/setup-ruby is guaranteed to have passed the entire test suite and ruby/spec, so big incompatibilities/breaking changes should not hit ruby/setup-ruby users.
And if they do, it is probably worth filing an issue upstream or improving the test suites or ruby/spec.

The reason I think testing against ruby-head is more useful is that there might be many incompatible changes between preview1 and the final release, and ruby-head will be closer to what the final release will be than preview1.
For instance, making sure you gem works on preview1 might actually not work on ruby-head and the final release, for instance if some new method of preview1 is used and that method is later renamed or removed.
Basically, testing compatibility with a preview is testing compatibility with an arbitrary and outdated development version.
I think the main purpose of previews is to try new things, knowing the APIs might change significantly, but not so much to test compatibility.

Given that, and that there is no plan to have Windows builds of previews (which would create inconsistency), I'd like for now to close this PR. I might reconsider, but for now it seems too high effort for too little gains.

[robotdana]

I'm persuaded thank you for your time :)

[JonRowe]

As a gem maintainer, I have to disagree and request this be reopened. For RSpec preview builds are much more useful than head because they represent a stable build that should work, head often contains things that are in progress and flux. We are safely able to get consistency with a preview build that we cannot with head, meaning we often have to allow failures for head for the stability of our builds, but we don't have that problem with previews.

[eregon]

Let's continue the discussion on ruby/setup-ruby#100 since that's what happened.