Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later?

• Status: Closed
• Assignee: -

[dmitry.pogrebnoy (Dmitry Pogrebnoy)]

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!

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

dmitry.pogrebnoy (Dmitry Pogrebnoy) wrote:

Having a clear, public roadmap would really help library and tooling authors (like IDE vendors) prepare for upcoming versions and provide better support.

I'm curious what kind of problems can happen to library and tooling author by bumping up the major version.
Can't you tell us if there is anything you expect?

[dmitry.pogrebnoy (Dmitry Pogrebnoy)]

Thank you for the clarification!

I just wanted to make sure there isn’t another release already planned beyond 3.5. For example, a 4.0 version with some other significant changes.
If it’s purely a versioning matter and 3.5 remains the next major release, that’s perfectly fine. I just wanted to confirm so we can plan ahead accordingly.

[ufuk (Ufuk Kayserilioglu)]

It seems like the next version of Ruby will be branded as 4.0, but that is completely a decision for @matz (Yukihiro Matsumoto) to make as he wishes. Ruby version numbers don't follow semantic versioning, so 4.0 doesn't mean that there will be breaking changes. Any major.minor version combination could have breaking changes, as it has known to happen.

With that said, does it still matter for you if the next version is named 4.0 or 3.5?

[dmitry.pogrebnoy (Dmitry Pogrebnoy)]

Thank you! The version number itself doesn’t affect anything on our side. Whether it’s released as 3.5 or 4.0, both are perfectly fine. I just wanted to make sure I’m not missing an extra release in between.

[bkuhlmann (Brooke Kuhlmann)]

I would also like to know if the next Ruby version is 3.5.0 or 4.0.0 precisely because Ruby doesn't follow Semantic Versioning. Having this knowledge sooner rather than later means I can pin my gemspecs to the correct version (and/or version range) for support purposes. Example:

# Assuming a Ruby 3.5.0 release.
spec.required_ruby_version = ">= 3.4", "<= 3.5"

# Assuming a Ruby 4.0.0 release.
spec.required_ruby_version = ">= 3.4", "<= 4.0"

[byroot (Jean Boussier)]

@bkuhlmann please don't restrict the upper versions unless you know for a fact it's incompatible. This prevent the community from testing early release and fixing the compatibility issues in advance. This practice is slowing the community down.

[retro (Josef Šimánek)]

@byroot (Jean Boussier) 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.

[byroot (Jean Boussier)]

@retro, hard disagree, because if everyone did what you suggest, it means that every year:

• You need to wait on every single one of you dependency to cut a new release with an updated gemspec. When you get hundreds of dependencies this may take months, or even never happen if the gem is abandoned.
• If in the meantime one dependency made a breaking change or bumped a major version, you need to migrate to the latest version of that gem before you can upgrade Ruby.

The same thing happen with gem that impose an upper version on Rails, it's extremely annoying and absolutely not practical.

I agree than in an ideal world, the bundler resolver would know about such incompatibilities, but they can't be known in advance.
IMO this is something that gem authors should be able to declare AFTER the gem is released not at release (but I understand this is challenging).

[retro (Josef Šimánek)]

@byroot (Jean Boussier) just to make it clear, I'm not saying I'm big fan of the current situation, but I just described how the whole ecosystem is designed right now. It is quite old rusty design, not being revisited for years. I agree with you to disagree this is good situation.

IMO this is something that gem authors should be able to declare AFTER the gem is released not at release (but I understand this is challenging).

This is something I was heavily exploring and I have some plans to help resolve.

[bkuhlmann (Brooke Kuhlmann)]

Jean:

Sorry, I didn't provide enough context to my original statement. Each year -- about ~2 months before Christmas when a new Ruby version drops -- I release a patch version of all my gems that accepts the current version and potential upcoming version. Example:

# Assuming a Ruby 3.5.0 release.
spec.required_ruby_version = ">= 3.4", "<= 3.5"

This gives the Ruby community some leeway (i.e. cross-over period) which supports the current Ruby version and the upcoming Ruby version. During this time, I'll test against both the old Ruby and the release candidates. Often, I'll report bugs here or bugs against the individual gems (which ever is most applicable).

Once the new version of Ruby drops on Christmas (let's say Ruby 3.5.0 for this year). I'll release major versions for all my gems where the gemspec requirement is now:

spec.required_ruby_version = "~> 3.5"

The reason I do this end-of-year dance each year stems from the following:

• Ruby doesn't adhere to Semantic Versioning so I can't rely on each new version of Ruby causing maintenance grief.
• Because each new Ruby can break functionality, I make sure to support the new syntax, drop the old syntax, etc.
• I maintain ~50 gems (over ~15 years now), which are constantly kept up to date. I've also been trying to obtain funding for years and never get any so I can't maintain backwards compatibility because it's too costly (on my time) and would lead to extreme burnout. This is why I release a major version each year because I adhere to Semantic Versioning in order to communicate that a the major upgrade might require some work on those that upgrade. If people don't want to upgrade right away, they can still stay on the old version but that means they basically have a year to get their act together and upgrade before this process repeats again a year later.

Again, this all stems from Ruby being chaotic with the version releases. If Ruby had more reliable version releases based on Semantic Versioning it means I could possible not have to release a major version of my own work each year with much more longer lived gem versions.

This also echoes what, Josef has pointed out above as well: It's the randomness of Ruby versions that is the killer.

This year is even worse because I can't even tell if Ruby will be a 3.5.0 or 4.0.0 release. 😢

[byroot (Jean Boussier)]

this all stems from Ruby being chaotic with the version releases

Well no. This all stems from you following a very inefficient and user-unfriendly workflow (which you are entirely free to).

I maintains 2x as many gems gems as you, with ~3000x as many downloads and I have none of your problems, and my users don't need to needlessly upgrade my gems. On every new ruby release, 99% of my gems don't need any change 🤷.

[retro (Josef Šimánek)]

Well no. This all stems from you following a very inefficient and user-unfriendly workflow (which you are entirely free to).

@byroot (Jean Boussier) Well yes, I think I have clearly stated that your workflow could be also very inefficient and user-unfriendly (which you are entirely free to). I agree your workflow is in the end best for gem consumers, but it requires to follow closely Ruby core development to be able to react in time for potential changes. If you're not maintainer doing this and you can't provide this guarantee to your gems, it is clearly safer to get a bit more defensive and the way @dmitry.pogrebnoy does this is IMHO good balance in between both. It is well known fact Ruby releases around Christmas, and just getting early reminder to check gems are still OK once per year, test and release new versions including new Ruby versions is optimal. In the end, common consumers will see no difference for both workflows - once new Ruby is out, they can resolve bundle.

I understand it is not simple to bring Semantic Versioning to Ruby, but please accept current versioning can cause those troubles and there is nothing wrong to ask. Ideally it would be nice to get friendly environment enough to let maintainer ask and get answer without being accused of being inefficient and providing user-unfriendly workflow.

I maintains 2x as many gems gems as you, with ~3000x as many downloads and I have none of your problems, and my users don't need to needlessly upgrade my gems. On every new ruby release, 99% of my gems don't need any change 🤷.

So how does this work? Are you self-titled ultimate gems overlord now (having this many downloads) and only your workflow is friendly and efficient? This arrogant behavior will not help motivate maintainers to keep their good work. Each gem maintainer deserves respect. Amount of active maintainers is decreasing each year, a lot of gems are being abandoned. This is not helping IMHO. It used to be friendly safe space in here. :sad-panda:

[byroot (Jean Boussier)]

This arrogant behavior

Arrogant? I'm just sharing my experience and the same metrics Brooke shared to put my experience in perspective.

This is not helping IMHO. It used to be friendly safe space in here. :sad-panda:

My intent was never to be unfriendly, but if that's how you feel I promise to never interact with you ever again.

[vo.x (Vit Ondruch)]

I agree with @byroot (Jean Boussier) that the upper bound restriction is from my experience very impractical.

As a maintainer of Ruby in Fedora, once we update Ruby in the distribution, we also make sure that all other packages are compatible with it. In such situation, the upper bout restriction is unhelpful. There are multiple scenarios, I'll name randomly just a few:

• There might be situations when such package passes it test suite, but later it is not usable just due to the metadata.
• There might be restriction in some of the package dependency chain, but then we cannot know if the bigger dependency chain is problematic, because e.g we cannot even execute test suites of packages, which on itself does not have any restrictions.
• If there is issue, contributing the fix to upstream is typically harder. It is one more thing which needs to be taken care of. Contributing fix, I want to provide solve the root cause, I don't want to maintain gemspecs, Gemfiles, CI settings etc. Mainly because various projects has various version support policies or capacities (and please don't take me wrong, sometimes our contribution maybe is just enabling CI for the latest Ruby version to highlight some problem).
• Part of the problem also is that while upstream might do outstanding work and supports whole Ruby version matrix, maybe the maintainer in Fedora disappears or is busy and suddenly the gem version in Fedora lags behind upstream, causing all sorts of issues, because we generally keep just single version of package which needs to be compatible with the rest of ecosystem.

[retro (Josef Šimánek)]

• There might be situations when such package passes it test suite, but later it is not usable just due to the metadata.

Yup, this is frustrating and I do understand for some it can justify open ended Ruby constraint. Let's find a solution for this instead. IMHO it will be great to be able to update metadata related to supported Ruby versions without releasing new gem version and if possible, make it automated (on success CI run once new Ruby is released). I'm working on something related currently.

[mame (Yusuke Endoh)]

Just adding my two cents to the off-topic discussion.

I honestly feel that the ~> constraint was a terrible idea. It's going to be a huge pain when Ruby 4.0 is released (at the end of this year, perhaps?), and all the gems locked to s.required_ruby_version = "~> 3.x" fail to install.

Setting an upper bound like this is ultimately bad for users.

See https://github.com/ruby/rubygems/pull/4109. Feels like we haven't learned anything since the Ruby 3.0 release, have we? 😅

[retro (Josef Šimánek)]

@mame (Yusuke Endoh) so why to release 4.0 if not causing major breaking changes?

[ufuk (Ufuk Kayserilioglu)]

retro (Josef Šimánek) wrote in #note-17:

@mame (Yusuke Endoh) so why to release 4.0 if not causing major breaking changes?

Quoting my answer to this from above:

... that is completely a decision for @matz (Yukihiro Matsumoto) (Yukihiro Matsumoto) to make as he wishes. Ruby version numbers don't follow semantic versioning, so 4.0 doesn't mean that there will be breaking changes.

[headius (Charles Nutter)]

I don't personally have a strong opinion about jumping to 4.0 purely for symbolic reasons, but if it's going to happen, it seems clear the community needs to know right now so we can start dealing with these issues.

JRuby made a leap from 1.7 to 9.x a decade ago, but 9.x involved a major rewrite of JRuby internals akin to the introduction of YARV. CRuby's jump to 3.0 was accompanied by major changes as well, primarily the formalization of keyword arguments. Even the move from JRuby 9.x to 10.x makes sense, with compatibility jumping three whole versions, and the the minimum JVM version requirement jumping from 8 to 21.

With Ractor remaining experimental, and only a modest number of visible changes to Ruby since 3.4, I would not personally bump the major version number for this release... but if I did, I would have made it official months ago. It seems too late to me at this point.

[retro (Josef Šimánek)]

ufuk (Ufuk Kayserilioglu) wrote in #note-18:

retro (Josef Šimánek) wrote in #note-17:

@mame (Yusuke Endoh) so why to release 4.0 if not causing major breaking changes?

Quoting my answer to this from above:

... that is completely a decision for @matz (Yukihiro Matsumoto) (Yukihiro Matsumoto) to make as he wishes. Ruby version numbers don't follow semantic versioning, so 4.0 doesn't mean that there will be breaking changes.

@ufuk (Ufuk Kayserilioglu) Sure, I'm aware of and I do fully respect this. Ruby itself is not simple to version, since next to the language (having amazing backwards compatibility usually) it is composed of various default and bundled gems, each having own versioning (I think mostly close to semantic) and vice versa. Writing this again (https://bugs.ruby-lang.org/issues/21657#note-3) brings nothing to the discussion.

@mame (Yusuke Endoh) I would not blame ~> operator for being terrible idea. It works usually well for semantic versioning. I would blame the missing guidance for gem maintainers how to specify required_ruby_version. Per my understanding, the only current recommendation (based on gem specification policy) is to add lower boundary aka saying this is the oldest support Ruby. I do fully understand the defensive approach (as reported by OP) adding also upper boundaries. Both have pros and cons and none is the only good one.

---

What are currently the most dangerous part to break gems with new Ruby release? I'm aware of some language changes (keyword args?) in Ruby 3.0, I'm aware of compiled extensions being broken sometimes (probably due to using private C APIs). Please share other cases if known.

Random ideas:

• introduce language standard versioning, that would make it clear both Ruby 3.4 and Ruby 4.0 are implementing same language standard (aka no breaking changes in language itself, safe to assume gem work in both versions, lock to this on gem level instead of Ruby version itself)
• make gem metadata dynamic, let's maintainers update the released gem supported ruby version after release (not simple to introduce currently, since it will most likely break the gem security hashes) - that will add new tool to maintainers' hands to test their gems and update support matrix without cutting new release (possibly even automating this and let the gem decide on its own if passing CI test suite)
• recommend not specifying upper ruby version boundary explaining Ruby core team puts some guarantees around this (maybe that's already happening and it is one gem specification policy away)

[Earlopain (Earlopain _)]

introduce language standard versioning, that would make it clear both Ruby 3.4 and Ruby 4.0 are implementing same language standard

Maybe they are but that is not the only important thing. Current news list a bunch of default gems that are now bundled which is pretty significant. cgi is also getting very similar treatment.

rack for example needed updates to work around the cgi changes, it didn't load otherwise. Users are able to add cgi to their gemfile to work around this but practically speaking versions of rack without knowledge about that change are broken with 3.5 or whatever else it may be called.

The majority of gems are unaffected by that particular change but rack is a pretty significant gem. Should this hypothetical version number be increased (specifically about "safe to assume gem work in both versions")? If you follow semantic versioning then surely it should be increased.

I feel like practically you would end up with a new semantic major version each year anyways.

Your third point is what I would want and is also already the case for majority of gems I'd say (one could actually confirm/deny this, all the data is out there). From a quick look, I did find minitest which currently would refuse to run on 4.0

What are currently the most dangerous part to break gems with new Ruby release?

Gems moving to being bundled is a not insignificant part of why gems have to be updated for new ruby versions these days.

It is always easy to work around for the user by adding it to their gemfile and usually there is one ruby version that warns in advance (+ it is usually easy to fix for the gem maintainer as well)

[mame (Yusuke Endoh)]

• Status changed from Feedback to Closed

Regarding the original topic of this ticket. I heard that @matz (Yukihiro Matsumoto) announced at RubyWorld Conference 2025 that the next release version will be Ruby 4.0.0. Also, Matz has set the master branch version to 4.0.0 as well.

6d81969b475262aba251e99b518181bdf7c5a523

Therefore, barring any major issues, the next version is expected to be 4.0.0.