Support Rails 6.1 through 8.1 on Ruby 3.0 through 3.4

[IgorFroehner]

Note

Stacked on #11 — base is chore/release-hygiene, so this diff shows only the dependency work. Merge #11 first and this retargets to master automatically.

The problem

The gem was installable on nothing current:

spec.required_ruby_version = ['>= 3.0', '< 3.4']
spec.add_dependency 'activerecord', '~> 6.1'

Ruby 3.4 and 3.5 are out, and Rails 6.1 has been EOL since late 2024. No supported Rails and no current Ruby satisfied both constraints at once. Every bug fix queued behind this would have shipped into a gem no modern app could add.

What it took

The library code needed no changes. That was the open question going in, and the answer is that lib/ is untouched in this diff.

One line in the spec harness was not compatible — MigrationContext.new took a required schema-migration class in 6.1, gained a default in 7.0, and dropped the argument entirely in 7.2. It is now selected on Active Record version.

Proving it rather than asserting it

Widening a constraint without testing the range is just a bigger claim. Added an Appraisal matrix — one gemfile and committed lockfile per Rails version — and all six run the full suite:

Appraisal	Result
rails-6.1	40 examples, 0 failures
rails-7.0	40 examples, 0 failures
rails-7.1	40 examples, 0 failures
rails-7.2	40 examples, 0 failures
rails-8.0	40 examples, 0 failures
rails-8.1	40 examples, 0 failures

CI expands to a Ruby × Rails matrix. The exclusions are measured, not guessed:

• Rails 6.1 and 7.0 on Ruby 3.4 fail with LoadError: cannot load such file -- mutex_m, which left the default gems in 3.4. Verified locally on 3.4.8; 7.1 and 7.2 pass on the same Ruby.
• Each Rails version is excluded below its own minimum Ruby.

On the two hand-pins

Only one of them was actually removable, which is not what I predicted:

• concurrent-ruby < 1.3.5 moves out of the root Gemfile into the 6.1 and 7.0 appraisals — the only versions it applies to. It no longer constrains everyone.
• rubocop-factory_bot ~> 2.23.0 stays. I removed it to check and got Property AutoCorrect of cop FactoryBot/CreateList is supposed to be a boolean and contextual is not — it constrains the linter toolchain against jetrockets-standard 1.29, not Rails, so the Rails upgrade does not release it. The comment in Gemfile is updated to say so.

Lockfiles

gemfiles/*.gemfile.lock are not committed, and neither is the root Gemfile.lock.

I tried committing them first, for reproducible matrix cells. It cannot work here: a lockfile records one Ruby's resolution, and each Rails version runs across several Rubies. The locks were generated on Ruby 3.3, so the 3.0 and 3.1 cells failed to install with i18n-1.15.2 requires ruby version >= 3.1. Serving every cell would need one lockfile per Ruby/Rails pair — 23 of them.

Each cell resolves on its own instead, which is what Appraisal expects. The trade-off is real and worth naming: an upstream release can turn CI red without a commit here. For a library that is arguably the point, since it is also how a user's install would break.

Also

• pg drops from runtime to development dependency. Revisions need PostgreSQL column types, but the adapter is the host app's to declare — this was blocking installation for anyone not already on pg.
• README gains the compatibility table, the PostgreSQL env vars the specs need, and how to run a single appraisal.
• spec/dummy/tmp/ added to .gitignore — generated by the generator specs.

Verification

• Six appraisals × full suite: 40 examples, 0 failures each
• Ruby 3.4.8 × Rails 7.1 / 7.2 / 8.1: 40 examples, 0 failures
• bundle exec rubocop — 48 files, no offenses
• gem build — 22 files packaged, unchanged from Ship only the library, and document how to install it #11