Drop support for end-of-life Ruby and Active Record

[nertzy]

Drops Ruby and Active Record versions that are out of support, adds the ones that have shipped since the matrix was last touched, and adds a contributing guide.

What is out of support

	released	status
Ruby 3.2	2022-12-25	end of life 2026-03-31
Active Record 7.0	2021-12-15	end of life
Active Record 7.1	2023-10-05	end of life

So required_ruby_version becomes >= 3.3 and the Active Record dependency becomes >= 7.2.

What is new

Ruby 4.0 shipped on 2025-12-25 and Active Record 8.1 on 2025-10-22; neither was tested here. Both are now in the matrix, along with 8-1-stable and a ruby-head canary that cannot fail the build.

The grid goes from 17 jobs to 14 — 9 required plus 5 that are allowed to fail — while covering more current versions than before.

Two dead Gemfile conditionals go away with 7.0

The Gemfile chose between sqlite3 1.x and 2.x per matrix leg, because Active Record 7.0's adapter requires sqlite3 ~> 1.4. With 7.0 gone the Gemfile just asks for sqlite3.

A self-audit turned up a second one next to it, which had been dead for longer:

gem "arel", git: "https://github.com/rails/arel.git" if ar_branch == "master"

Three separate reasons it could never do anything: nothing sets ACTIVE_RECORD_BRANCH=master (the workflow tests main), Rails has not had a master branch in years, and rails/arel has been untouched since 2018 because Arel was merged into Active Record in 6.0 — activerecord 8.1.3 lists activesupport, activemodel, and timeout, with no arel among them. Removed, and the *-stable legs that exercise that code path are green.

The sqlite3 advisory

Dropping the pin also closes out the advisory reported against this repository: a use-after-free in sqlite3 <= 2.9.4, patched in 2.9.5. The pinned legs could never have taken that fix, since 1.x is not in its range. Now every leg resolves 2.9.5.

Verified locally

Both floors and both ceilings, on real interpreters rather than by inspection:

	Active Record 7.2	Active Record 8.1
Ruby 3.3	130 examples, 10 runs	130 examples, 10 runs
Ruby 3.4	130 examples, 10 runs	130 examples, 10 runs
Ruby 4.0	130 examples, 10 runs	130 examples, 10 runs

All green, zero failures.

Workflow structure

The first commit restructures the workflow before any versions change, so the version diff is readable on its own. It follows pg_search, which had already solved the same problems:

• Checks were named test (3.2, ACTIVE_RECORD_VERSION="~> 7.0.0", false) — hard to scan, and leaking the continue-on-error flag into the name. They are now Ruby 3.3 / AR 8.1.
• The Active Record version is written to GITHUB_ENV in its own step rather than prefixed onto each command, so a matrix value is no longer interpolated into a shell script.
• Pull requests cancel their own superseded runs, the job has a timeout, and the workflow requests only contents: read.

That commit changes how the jobs are named and set up, not which ones run: I confirmed the matrix expands to the same 17 (ruby, env, allow-failure) tuples before and after.

Contributing guide

CONTRIBUTING.md, adapted from pg_search's. The parts specific to this gem are the two suites — spec/ for behavior under RSpec, test/ for the minitest life cycle rather than a second copy of the specs — and the two environment variables for selecting an Active Record, which take a version requirement and a git branch respectively. It also asks contributors to leave version.rb alone and add to the Unreleased changelog section.

Linked from the README, which otherwise had nothing pointing at how to run the tests.

Worth knowing

Active Record 7.2 goes out of support on 2026-08-09, twelve days from now. This floor has days left rather than months, so a follow-up moving it to 8.0 is worth expecting shortly. I have kept 7.2 rather than pre-emptively dropping it, since it is supported today.

The README defers to the gemspec for supported versions instead of listing them, so it needed no version edit here — that indirection is why it has not drifted.

Each commit passes bin/rake on its own.

Ruby 4.0 needed bundle exec

The first push of this branch failed every Ruby 4.0 job with bin/rake: No such file or directory, while 3.3 and 3.4 passed. bin/ holds generated binstubs and is not checked in, so CI only ever had one because bundling wrote it — and whether bundling does that varies by Bundler version. Ruby 4.0 ships Bundler 4, which does not, so there was nothing to run.

Tests now run through bundle exec rake, as pg_search's do, and bundle update gains --all — required by Bundler 4, and already the meaning under Bundler 2.

Worth recording that my local "verified on Ruby 4.0" claim above was wrong when I made it: a stale binstub from a Ruby 3.x run was sitting in my working copy, so bin/rake resolved locally and hid the problem. The table's results are real, but they were produced with binstubs present. I re-ran all three Rubies with bin/ removed to confirm the fix, and CI now agrees.