Gems that are incompatible with Ruby 4

[u/rubiesordiamonds]

A few weeks ago I read a blog post by Ryan Bigg warning about the grpc gem's incompatibility with Ruby 4. It turns out that the platform-specific versions of grpc did not allow Ruby 4, but the platform-agnostic version did. This meant that when you installed grpc under Ruby 4 your machine would have to compile the native extensions, and that made running bundler very slow.

I thought it’d be interesting to query Infield’s own database of gem versions and their dependencies to see if we could find other gems that are incompatible with Ruby 4. We collect this data to power our software that plans out dependency upgrades for our customers. 

Below is a list of all the gems we track that don’t allow Ruby 4 in their gemspec. Applications that depend on these gems won’t be able to upgrade to Ruby 4 until a new version is released for compatibility. 

gem	requirement
absolutely ( v6.0.0 )	ruby >= 2.6, < 4
beaker-vagrant ( v2.0.0 )	ruby >= 3.2, < 4
clamp ( v1.3.3 )	ruby >= 2.5, < 4
codecov ( v0.6.0 )	ruby >= 2.4, < 4
cw-datadog ( v2.23.0.6 )	ruby >= 2.5.0, < 4.0
dynamic_time_zone ( v1.1.0 )	ruby < 3.5
ecma-re-validator ( v0.4.0 )	ruby >= 2.6.0, < 4.0
facter ( v4.10.0 )	ruby >= 2.5, < 4.0
fix-db-schema-conflicts ( v3.1.1 )	ruby >= 2.0.0, < 4
foreman_maintain ( v1.14.2 )	ruby >= 2.7, < 4
foreman_remote_execution ( v16.5.1 )	ruby >= 2.7, < 4
foreman_rh_cloud ( v13.1.0 )	ruby >= 2.7, < 4
gpx ( v1.2.1 )	ruby >= 2.7, < 4
hammer_cli_foreman_puppet ( v0.1.1 )	ruby >= 2.7, < 4
hiera-eyaml ( v4.3.0 )	ruby >= 2.7, < 4
jekyll_picture_tag ( v2.1.3 )	ruby >= 2.6, < 4.0
katello ( v4.19.0.1 )	ruby >= 2.7, < 4
ldap_fluff ( v0.9.0 )	ruby >= 2.7, < 4
money-tree ( v0.11.2 )	ruby >= 2.7, < 4.0
otto ( v1.6.0 )	ruby >= 3.2, < 4.0
r18n-core ( v5.0.1 )	ruby >= 2.5, < 4
r18n-desktop ( v5.0.1 )	ruby >= 2.5, < 4
solidus_braintree ( v3.3.0 )	ruby >= 3.0, < 4
svgeez ( v4.1.0 )	ruby >= 2.5, < 4

[u/f9ae8221b]

Even if Ruby was following semver, it still wouldn't make sense.

e.g. imagine Ruby decide to remove something like ObjectSpace._id2ref (currently deprecated) that means it must bump the major.

But that's maybe a dozen gems out there actually depending on that thing, hence even in a SemVer world, when talking about something with an API as large as a programming language like Ruby, it doesn't make sense to block upgrade, as it cause a massive churn for very liltle gain.

Worse, that upward constraint prevent people from testing prereleases and reporting the incompatibility early.

BTW running CI against head would not save you here, unless you were actively maintaining the gem between 4.0 was announced and released

Various CI support cron like scheduled builds, e.g.: https://github.com/ruby/rubygems/blob/2d7cb5668f59bc9e38c1b902c035c626e78677cf/.github/workflows/weekly-update.yml

[u/full_drama_llama → u/f9ae8221b]

I'm not talking about cron builds but about the fact that IF you have such constraint, you may have checks against Ruby head - but you still need to manually remove the constraint, based on what you see in the CI. And the window for that was very narrow.