From: retro via ruby-core Date: 2025-11-05T22:11:55+00:00 Subject: [ruby-core:123695] [Ruby Misc#21657] Question: Is Ruby 4.0 planned for December 2025 or later? Issue #21657 has been updated by retro (Josef ��im��nek). ufuk (Ufuk Kayserilioglu) wrote in #note-18: > retro (Josef ��im��nek) wrote in #note-17: > > @mame so why to release 4.0 if not causing major breaking changes? > > Quoting [my answer to this](https://bugs.ruby-lang.org/issues/21657#note-3) from above: > > ... 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. @ufuk 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 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) ---------------------------------------- Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later? https://bugs.ruby-lang.org/issues/21657#change-115078 * 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/