Remove spec.has_rdoc from the gemspec (RubyGems 4 / Ruby 4.0 compat) - #1
freshaengineering-spirit-bot[bot] wants to merge 1 commit into
Conversation
RubyGems 4 (shipped with Ruby 4.0) removed Gem::Specification#has_rdoc=, which makes loading this gemspec raise NoMethodError and blocks any consumer from resolving dependencies under Ruby 4.0.
![freshaengineering-spirit-bot[bot]](https://avatars.githubusercontent.com/u/291033831?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: approve. (Formal approve state is unavailable because the PR is authored by the team bot; treat this as the review verdict.) Adversarial pass, with empirical validation — I loaded and built the gemspec under this sandbox's Ruby 3.4.1 / RubyGems 3.6.2 on both the base and the PR branch.
The fix is correct, and the claim is confirmed by RubyGems itself. Loading the old gemspec under 3.6.2 emits exactly the warning this PR cites: Gem::Specification#has_rdoc= is deprecated with no replacement. It will be removed in Rubygems 4 — the runtime names has_rdoc= as a 4.0 removal, and "no replacement" means deletion is the entire fix (nothing to migrate to). Loading the new gemspec (this PR) under 3.6.2 is clean, and gem build sea.gemspec succeeds on the PR branch (sea-0.1.0.gem built) — so consumers still on Ruby 3.x are unaffected; removal is backward-compatible, not a trade.
Completeness — this is the only RubyGems-4 blocker in the gemspec. The old gemspec produces exactly one "will be removed in Rubygems 4" warning (has_rdoc=); spec.test_files gets no such warning, consistent with the PR's claim that it still works under 4 (correctly left out of scope — deleting it would be churn). The rest of the gemspec (extra_rdoc_files, add_development_dependency, files, require_paths, platform, license) uses only current API. Bundler also evaluates lib/sea/version.rb when loading the gemspec — I checked it: trivial (VERSION = '0.1.0'.freeze), nothing removed in Ruby 4.0, no removed-API use anywhere in lib/. So app-shedul's bundle genuinely unblocks under 4.0 once this lands.
Scope discipline — exact. One line deleted, nothing else.
Repo context — noted, and the PR body reads it right. This repo has no CI of its own (no .github/workflows — only the org-level Socket/StepSecurity checks, both green), so there is nothing to break; the meaningful validation is gemspec load + build, which I ran locally and passes. Consumption model verified: app-shedul's Gemfile pins gem "sea", "~> 0.1.0", git: .../sea-ruby.git with no ref — consumers track master via locked revisions. So no gem-server release or tag is needed; consumers pick the fix up on their next bundle lock --update sea — which also means app-shedul's runtime-bump PR must refresh its lockfile after this merges (the stacking the body already describes). The stale-repo ownership flag (untouched since 2019, not in houston's registry) is a correct heads-up for routing.
Non-blocking nits, for whoever owns this repo next: spec.homepage still points at the old surgeventures org, and required_ruby_version is unset (gem build's advisory warning) — both pre-existing, harmless under git-source consumption, out of scope here.
Why
sea.gemspecsetsspec.has_rdoc = false. RubyGems 4 — which ships with Ruby 4.0 — removedGem::Specification#has_rdoc=, so evaluating this gemspec now raises:That blocks any consumer of
seafrom resolving or installing dependencies under Ruby 4.0 — no bundler version works around it, because the gemspec itself fails to load.What changed
One line deleted (
spec.has_rdoc = false). Nothing else —spec.test_files(also deprecated) is left alone deliberately: it still works under RubyGems 4 and is out of scope.Consumer impact
This came up bumping app-shedul (the Rails monolith) from Ruby 3.4.1 → 4.0.7 for the
runtime-version-currentscorecard rule: itsbundle installcrashes on this gemspec, and app-shedul's runtime bump PR is stacked on this fix landing (its lockfile will pick up the newsearevision once merged). app-reports already runs Ruby 4.0; if any other Ruby 4.0 consumer picks upsea, they need this too.Note: the repo's default branch (
master) is what consumers' lockfiles track — merging this changes the pinned revision every consumer sees on their nextbundle lock --update sea. That's the point, but worth knowing.Origin: Slack thread.