feat: ruby 3.3 minimum (#28001)

[larouxn]

Drop support for EOL Ruby 3.2. Update gemspecs, templates, and CI configuration. (EOL source)

Based on #26608
Resolves #28001

[seuros]

Thanks for opening the PR.

I opened the issue, hoping the maintainers will go full edge (4.0-4.1)

We are in late 2026 and there is absolutely no reason to not be able to upgrade to latest either with grep or with AI.

Every app i worked on that use this gem, was always in edge.

[larouxn]

I opened the issue, hoping the maintainers will go full edge (4.0-4.1)

I don't think they will drop support for non-EOL Rubies such as 3.3 and 3.4 but I definitely think they should drop support for 3.2, which has been EOL for almost half a year.

[larouxn]

Rebased on latest main to pick up fixes from #28043.

[quartzmo]

Thanks for putting this together. Our published support policy (https://cloud.google.com/ruby/getting-started/supported-ruby-versions) keeps the most recently end-of-life Ruby supported for 12 months after its EOL date. Ruby 3.2 reached EOL on 2026-03-31, so under that policy it stays supported until around April 2027, when we drop it across all of our Ruby repos together. The README wording here says "not end of life", which appears to contradict the policy, so we'll look into that. For now I need to close this PR, but I'll leave #28001 open.

[seuros]

@quartzmo , Respectfully, a "published support policy" is a strange thing to cite from the company that keeps a product graveyard big enough to have its own memorial site.
Google has never had trouble dropping things when it suited it. It only seems to find patience when the thing to drop is a Ruby runtime that nobody patches anymore.

The policy actually says:
> "compatible with all actively supported Ruby releases, plus the most recently end-of-life release for 12 months after the end-of-life date."

It says compatible. It does not say secure or patched. Ruby core stopped fixing 3.2 on 2026-03-31, and the results are already showing:

• CVE-2026-80212 / CVE-2026-80213: memory exhaustion through malicious DNS responses, plus a hostname validation bypass that gets past SSRF allow-lists. From Ruby core's own advisory: "No release is
  planned for the 0.2.x line that the Ruby 3.2 series ships, because that series has reached its end of life."
• CVE-2026-41316: a Marshal deserialization guard bypass, which means RCE in any app that loads ERB and ActiveSupport. That covers every Rails app. It's fixed in 3.3.12 and 4.0.3. There is no 3.2 release.

There are more bugs that did not get CVE because the world moved to the future. These 3 are in the hotpath of this gem.

So in practice the policy means: "we'll keep using CI for another six months to prove our client still runs on a runtime that upstream has said, in writing, it won't fix."

Your own README also disagrees with you:

"Google provides official support for Ruby versions that are actively supported by Ruby Core -- that is, Ruby versions that are either in normal maintenance or in security maintenance, and not end of life."

@larouxn followed it. And the last condition matters.

Just for info, since the ground is moving under you: Matz's Spinel, the AOT compiler, is supporting CRuby 4.0+ and compiles Ruby applications, gems included, into native binaries. That is where the ecosystem is going.

Several of this gem's dependencies are already discussing dropping 3.x and requiring 4.0. I co-maintain many of them so I'm not repeating rumours. Once those releases ship, this gem has two choices. It can adapt, or it can stay pinned to unmaintained versions of its own dependency tree and hand-roll whatever breaks. Your 12-month grace period won't matter, because your dependencies don't follow it. And no security patch is not going to be backported , so you will have scanners screaming at your users that the gem is unsafe.

I hope this thread doesnt get noticed by security researchers before you reconsider how rigid this policy is.

[quartzmo]

@seuros Can you please repost this comment to #28001? Maybe excluding the little rant about Google in general (big company), but definitely including the critique of the cloud.google.com policy wording, the example CVEs, and CRUBY/4.0/dependencies context. This is valuable input. If you don't copy it to the open bug, I will, but it will have more impact coming from you. Thanks!

[seuros]

Absolutely . Sorry for the direct tone.

Normally when i reject a issue/PR , i let the submitter a chance to respond or close their own issue/PR.

I recently got many PRs closed then locked by other big companies especially when they see my github history and think i unleashed on them some AI bot. (this is why i opened an issue here not the PR).

Anyway I will edit the issue tomorrow.

PS: i will help with refactoring and cleaning up this gem, as you can see i already contributed to it before.

[quartzmo]

Anyway I will edit the issue tomorrow.

Thank you! I will make sure it gets read and understood.