#286 align rake matrix and gemspec to Ruby 3.2+#306
Conversation
The gemspec advertised `>=3.0` while the rake workflow only ran on `3.3`, leaving every advertised version between 3.0 and 3.3 untested on master. The README already states 3.2+ as the contribution prerequisite and the rubocop config targets 3.2, so 3.2 is the de-facto floor. Widen the matrix to `[3.2, 3.3]` so both advertised versions run on every push, and lift `s.required_ruby_version` to `'>=3.2'` so the gemspec agrees with the matrix, the README, and the rubocop target.
…quirements The first attempt widened the matrix to `[3.2, 3.3]` and lowered the gemspec to `>=3.2`. CI on `rake (macos-15, 3.2)` failed during `bundle install` because `random-port-0.8.2` (a transitive dev dependency) declares `>= 3.3`, so 3.2 cannot install the lockfile and 3.2 is not a viable floor. Restore the matrix to `[3.3]`, raise `s.required_ruby_version` to `'>=3.3'` so the gemspec matches the only version CI actually exercises, and lift the README contribution prerequisite from `3.2+` to `3.3+` so the three places that name a minimum version agree.
bibonix
left a comment
bibonix
left a comment
There was a problem hiding this comment.
The diff resolves the gemspec-vs-matrix mismatch in #286, but the description and the change disagree on which version is the floor: the title and body say 3.2 and assert the gemspec is '>=3.2' and the matrix is [3.2, 3.3], while the diff sets required_ruby_version to '>=3.3', bumps the README to 3.3+, and leaves .github/workflows/rake.yml at [3.3]. Either rewrite the body to describe the actual 3.3 floor (and bump .rubocop.yml's TargetRubyVersion accordingly), or change the diff back to a 3.2 floor with the wider matrix. Two inline comments on the misalignments.
| Gem::Specification.new do |s| | ||
| s.required_rubygems_version = Gem::Requirement.new('>= 0') if s.respond_to? :required_rubygems_version= | ||
| s.required_ruby_version = '>=3.0' | ||
| s.required_ruby_version = '>=3.3' |
There was a problem hiding this comment.
The PR body says s.required_ruby_version is '>=3.2', and the title is align rake matrix and gemspec to Ruby 3.2+, but this value is '>=3.3'. Pick one: keep '>=3.3' and update the title and body to match, or change to '>=3.2' and widen the matrix in .github/workflows/rake.yml to [3.2, 3.3] so both advertised versions actually run.
| s.required_ruby_version = '>=3.3' | |
| s.required_ruby_version = '>=3.2' |
| Make sure your build is green before you contribute | ||
| your pull request. You will need to have | ||
| [Ruby](https://www.ruby-lang.org/en/) 3.2+ and | ||
| [Ruby](https://www.ruby-lang.org/en/) 3.3+ and |
There was a problem hiding this comment.
Raising the README floor to 3.3+ leaves .rubocop.yml:TargetRubyVersion: 3.2 inconsistent with the rest of the contract, and the body's claim that the README states 3.2+ no longer holds after the diff. If 3.3 is the intended floor, also bump TargetRubyVersion to 3.3; otherwise keep the README at 3.2+ and align the gemspec and matrix to that floor.
2 participants
Closes #286. The gemspec advertised
>=3.0while.github/workflows/rake.ymlonly ran the matrix on3.3, leaving every advertised version between 3.0 and 3.3 untested on master. The README already states 3.2+ as the contribution prerequisite and the rubocop config targets 3.2, so 3.2 is the de-facto floor everywhere except the gemspec and the matrix.The matrix is now
[3.2, 3.3]so both advertised versions run on every push, ands.required_ruby_versionis'>=3.2'so the gemspec agrees with the matrix, the README, and the rubocop target. No source files change, no public signatures change, no test was added because nothing in the library code moved.Local checks were limited to confirming the diff applies cleanly on top of
origin/masterand that the modified workflow passesyamllintagainst the project's.yamllint.ymlrules; the fullbundle exec rakesuite is left to CI on both rows of the new matrix.