Fix release workflow docs and Ruby 3.2 bundle install

[justin808]

Summary

This unblocks maintainers running the release workflow on modern macOS + Ruby 3.2 while keeping the existing Ruby 2.7 CI matrix compatible.

Changes

• Pin development nokogiri in Gemfile to ~> 1.15.7
  • avoids resolving to nokogiri 1.19+ (Ruby 3.2+ only)
  • keeps compatibility with Ruby 2.7 CI and Ruby 3.2 local environments
• Update Gemfile.lock:
  • byebug 11.0.1 -> 11.1.3
  • nokogiri 1.14.3 -> 1.15.7 (including arm64-darwin platform entry)
• Fix stale example in rakelib/create_release.rake description:
  • rake release[...] -> rake create_release[...]
• Add dry-run release example to CONTRIBUTING.md

Verification

• mise exec ruby@3.2.9 -- bundle _2.4.9_ install
• mise exec ruby@3.2.9 -- bundle exec rake -D create_release

[claude]

PR Review: Fix release workflow docs and Ruby 3.2 bundle install

Overall this is a clean, well-scoped PR with a clear motivation. The changes are low-risk and address a real maintainer pain point. A few observations below.

---

Documentation fixes (CONTRIBUTING.md, rakelib/create_release.rake)

rakelib/create_release.rake — The fix from rake release[...] to rake create_release[...] is correct and important; stale examples in rake task descriptions are a common source of confusion.

CONTRIBUTING.md — The dry-run example is a useful addition. One small suggestion: the example uses 2.7.0 which coincidentally matches the Ruby version mentioned in the bullet above it. Consider using a placeholder like X.Y.Z or a clearly fictional version (e.g., 9.9.9) to avoid any reader confusion between the gem version and the Ruby version.

---

Gemfile — nokogiri pin

The pin and its comment are well-explained. ~> 1.15.7 (pessimistic patch constraint) is the right granularity here — it allows patch releases within 1.15.x while blocking the Ruby 3.2+ requirement introduced in 1.16+.

Minor pre-existing issue (not introduced by this PR, but worth noting): the Gemfile source is http://rubygems.org rather than https://. RubyGems.org redirects HTTP to HTTPS, but it would be good to update this to https://rubygems.org at some point to avoid any network-level interception risk.

---

Gemfile.lock

The lockfile changes look correct for a multi-platform bundle. A few things to verify:

1. byebug 11.0.1 → 11.1.3 — This appears to be a side effect of running bundle update nokogiri (or possibly bundle install on a newer Ruby). byebug is unrelated to nokogiri, so if this was pulled in unintentionally, consider whether bundle update nokogiri (scoped update) would produce a tighter diff. Not a blocker, just worth being intentional about.

2. Platform entries: The old nokogiri (1.14.3-x86_64-darwin) entry is replaced by separate nokogiri (1.15.7-arm64-darwin) and nokogiri (1.15.7-x86_64-darwin) entries, and arm64-darwin-23 is added to PLATFORMS. This looks correct for Bundler's multi-platform lockfile behavior. The x86_64-darwin-20 and x86_64-linux platforms are preserved, so existing CI should be unaffected.

3. CI verification: It would be worth confirming the existing x86_64-linux CI matrix passes with this lockfile (i.e., that bundle install resolves cleanly on Ruby 2.7 with the x86_64-linux platform), since that's the primary compatibility goal of this PR.

---

Summary

Area	Assessment
Documentation fixes	Correct and helpful
nokogiri pin	Well-reasoned, appropriate constraint
Lockfile changes	Correct; minor question about byebug bump scope
Test coverage	N/A — infrastructure/docs only
Security	No new concerns introduced; pre-existing http:// source URL worth a follow-up

The core goal — unblocking maintainers on modern macOS + Ruby 3.2 while keeping Ruby 2.7 CI green — is well-served by these changes. Nice work keeping the scope tight.