Issue #21657 has been updated by retro (Josef Šimánek). @byroot I would not suggest this in general. It can work both ways. Having strict Ruby constraints help to revisit gems after new Ruby release and provides confidence to resolver to install only tested versions for given Ruby. What you suggest can end up with locked versions in app Gemfile's because of incompatibilities which literally means now each app maintainer should test the gems and decide if safe to run with their apps and Ruby versions. Respecting `required_ruby_version` was added to resolver to do exactly opposite and let the gem owner decide which versions are safe to run. It was reason to implement warning for the opposite case (not scoping the oldest version) https://github.com/ruby/rubygems/pull/5010 and IMHO it will make the same to do the opposite, since currently Ruby versioning is quite "random" and it seems there is no plan to change it, which means any operator to compare open versions makes it just lottery. ---------------------------------------- Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later? https://bugs.ruby-lang.org/issues/21657#change-115041 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Feedback ---------------------------------------- Hello Ruby core team, I noticed that the first preview of Ruby 3.5 has been released, and at the same time there’s some talk in the community about Ruby 4.0 potentially arriving in December 2025. Could you please clarify what the current roadmap looks like? Is Ruby 4.0 already planned for this December, or is the next stable release still Ruby 3.5? Having a clear, public roadmap would really help library and tooling authors (like IDE vendors) prepare for upcoming versions and provide better support. Thank you! -- https://bugs.ruby-lang.org/