Fails with 3.0 or 3.0.0 in .ruby-version

[dentarg]

From #100 (comment)

Example at https://github.com/dentarg/actions-test/runs/1478584340?check_suite_focus=true#step:3:8

Run ruby/setup-ruby@v1
  with:
    ruby-version: default
    bundler: default
    bundler-cache: false
    working-directory: .
Using 3.0.0 as input from file .ruby-version
Error: Unknown version 3.0.0 for ruby on ubuntu-18.04
        available versions for ruby on ubuntu-18.04: 2.1.9, 2.2.10, 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5, 2.3.6, 2.3.7, 2.3.8, 2.4.0, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.9, 2.4.10, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.6.5, 2.6.6, 2.7.0, 2.7.1, 2.7.2, 3.0.0-preview1, head, debug
        File an issue at https://github.com/ruby/setup-ruby/issues if would like support for a new version

https://github.com/dentarg/actions-test/runs/1478584340?check_suite_focus=true#step:3:8

Run ruby/setup-ruby@v1
  with:
    ruby-version: default
    bundler: default
    bundler-cache: false
    working-directory: .
Using 3.0 as input from file .ruby-version
Error: Unknown version 3.0 for ruby on ubuntu-18.04
        available versions for ruby on ubuntu-18.04: 2.1.9, 2.2.10, 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5, 2.3.6, 2.3.7, 2.3.8, 2.4.0, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.9, 2.4.10, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.6.5, 2.6.6, 2.7.0, 2.7.1, 2.7.2, 3.0.0-preview1, head, debug
        File an issue at https://github.com/ruby/setup-ruby/issues if would like support for a new version

[eregon]

Thanks for the report and link to the runs! I will try to repro and investigate soon.

[eregon]

The change was in part intentional in 7c2bf72

So ruby (which means latest CRuby) should resolve to 2.7.2 currently, and not to 3.0.0-preview1.
In other words, 3.0.0-preview1 is not a stable version/full release.
What I thought is that non-stable versions should always be explicit (detailed below), and *-head should be used instead/additionally if wanting to track "latest build for the upcoming version".

I can see that 3, 3.0 or 3.0.0 might be convenient in the same way that e.g. 2.7 is, to pick the latest version starting with that partial version.

But, automatically picking 3.0.0-preview1/2/3, then 3.0.0-rc1/2/3 then 3.0.0 from ruby-version: 3.0 might be a bit odd, I'm not sure it's really intended.
If the intent is to test against latest changes in Ruby ruby-head might be a much better target, because potential breaking changes will appear a lot sooner and there will be a new build every day.

The essential question is do you want your CI to potential break when the next preview or RC is released?
There is almost no guarantee of compatibility between e.g. preview1 and preview2, same between the last preview and rc1. And maybe some limited compatibility between RCs. But all of these versions are considered unsupported, only full releases are supported (as in e.g. appropriate to run in production), at least that's my understanding of CRuby releases.
OTOH releases with the same major.minor like 2.6.n and 2.6.(n+1) should be very compatible, and it's reasonable to pin to just 2.6 and not 2.6.6.

I assume most people wouldn't want their CI to fail just because there is another preview, and would rather update manually to e.g. 3.0.0-rc1 or 3.0.0 and at that point ensure all tests pass.
If having the CI fail from changes in CRuby is wanted, then ruby-head seems a much better version to track.

A trade-off of this is that matching versions is as a result more complicated currently (differs for stable and unstable versions).

Does that make sense?
Would you want your CI to potentially fail when preview2 is released and there is a build on you repo? (due to specifying ruby-version: 3.0.0)
Do you also test against ruby-head?

[dentarg]

I understand that running a preview version of Ruby isn't the norm, but for a small personal app, that runs on Heroku, I switched to 3.0.0, just to test it out, for fun (and profit? 🤔).

Heroku made 3.0.0-preview1 available in September and says put ruby "3.0.0" in the Gemfile to use it. So I did that.

The essential question is do you want your CI to potential break when the next preview or RC is released?

Actually yes :)

I assume that if there is 3.0.0-preview2, and Heroku makes it available, 3.0.0 would resolve to that (and when Ruby 3.0 is released, 3.0.0 will resolve to that). I've configured my app to deploy to Heroku only if CI passes. So it would be good if CI failed then!

I'm guessing the reason Heroku says to use the string 3.0.0 and not 3.0.0-preview1 is Bundler, as Bundler refuses to bundle with ruby "3.0.0-preview1" in the Gemfile:

$ cat .ruby-version
3.0.0-preview1

$ cat Gemfile
# frozen_string_literal: true

ruby File.read(".ruby-version")

source "https://rubygems.org"

git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }

gem "puma"
gem "sinatra"

$ bundle
Your Ruby version is 3.0.0, but your Gemfile specified 3.0.0.pre.preview1

$ bundle --version
Bundler version 2.2.0.rc.2

(I didn't understand this when I posted #100 (comment))

Re: using 3.0 instead of 3.0.0, that could be an option, seems like Bundler allows that for 3.0

$ ruby -v
ruby 3.0.0preview1 (2020-09-25 master 0096d2b895) [x86_64-darwin18]

$ bundler -v
Bundler version 2.2.0.rc.2

$ cat .ruby-version
3.0

$ bundle
Using bundler 2.2.0.rc.2
Using ruby2_keywords 0.0.2
Using mustermann 1.1.1
Using nio4r 2.5.4
Using puma 5.1.0
Using rack 2.2.3
Using rack-protection 2.1.0
Using tilt 2.0.10
Using sinatra 2.1.0
Bundle complete! 2 Gemfile dependencies, 9 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

...but didn't for earlier versions

$ ruby -v
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin18]

$ bundler -v
Bundler version 2.1.4

$ cat .ruby-version
2.7

$ bundle
Your Ruby version is 2.7.2, but your Gemfile specified 2.7

[eregon]

That announcement from Heroku seems a bit confusing, but it is what it is.
(notably I'm not sure it's a good idea to test compatibility with previews, but I guess if ruby-head is not available then it's better than nothing. Probably what is more meaningful is to test on 2.7 and make warnings as errors).

OK, since this is actually behavior that might be wanted I'll let 3 & 3.0 & 3.0.0 to resolve to 3.0.0-preview1.
A good part of why I think it makes sense is it makes version matching simpler from a user point of view:
"the latest version that starts with the input version, considering stable versions before unstable versions".

[eregon]

Released as https://github.com/ruby/setup-ruby/releases/tag/v1.54.0

[eregon]

FYI, 3.0 is unfortunately misparsed by GitHub Actions, so it's safer to use '3.0' until that's fixed:
actions/runner#849

[dentarg]

Thanks! (3.0 and 3.0.0 in .ruby-version worked fine (I guess they come out as strings), that's enough for me)