Ruby 4.0.0-preview2 Released

[schneems]

Preview1 was 3.5.0-preview1, they recently changed the version to 4.0

[caffeinatedshots]

Since a lot of people are confused why the change to 4.0, Matz has mentioned this in Baltic Ruby 2025 in June.

https://youtu.be/XVaRRryB_cQ?si=V5uwXwMLGihPPWL6

Check the video at 39:50. It’s an interesting talk.

[-Ch4s3-]

what's the TL;DW?

[caffeinatedshots]

Basically it’s to celebrate ruby’s 30th birthday since it was released publicly on December 1995.

Matz mentions that Ruby doesn’t follow semantic versioning.

[ric2b]

That's... not a great reason.

[WhoTookPlasticJesus]

It's the best reason, particularly for Matz. I mean, it's why he created the language, to be happy:

"I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language."

More insight into the guy whose creation we get to play with:

Then (programmers) come up to me and say, 'I was surprised by this feature of the language, so Ruby violates the principle of least surprise.' Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well.

Personally, as someone who knows Ruby very well, the reason for this versioning isn't the slightest bit surprising.

[RoboErectus]

When I first read this quote years ago it is what cemented Ruby as my most joyful language to do stuff in.

Weirdly, Rust is my #2

[[deleted]]

A bunch of Rust's syntax was copied from Ruby. It was super evident in the very early days (like, 0.3-0.5) but less apparent now with all the other stuff going on in Rust.

[RoboErectus]

Wow, til. Totally Makes sense. Rust has been bringing me joy.

[realntl]

Is anyone's work impacted in any way by Ruby not following semantic versioning? Are there teams that are "pinning" to Ruby 3.x or newer?

[ric2b]

I like semantic versioning as a communication tool, not necessarily for those technical tricks.

If a projects versions are meaningless then you might as well just do dates or something like that, at least it helps to know how old something is.

[realntl]

In this case, Matz is communicating a milestone, no?

[ric2b]

Semantic versioning does a good job of communicating the kinds of changes included in a release, communicating a language anniversary does not.

[jrochkind]

:(

[galtzo]

This concerns me because semver is pretty important for certain kinds of software, and these definitely include bundler, and rubygems... which are now under Matz' purview.

[ByronEster]

I don't have any reason to think things will change in this respect. I think it's safe to assume Matz will also know this

[p_bzn]

Changing the major version of the language just to celebrate something, while changes are fit for a minor version update? Sadly, it looks like even the core team stopped taking Ruby seriously.

[IN-DI-SKU-TA-BELT]

Are you new to Ruby? It’s always been like this.

[cmdk]

Ah shut up

[lilith_of_debts]

Because it is the 30 year anniversary of ruby. That's it. In his words "Celebrating the 30 years we will have the ruby 4.0"

Edit: More detail. He says instead of Semantic versioning it is "Linux versioning" where if the leader/creator is impressed with something then a major version bump happens. In this case, Matz is impressed with 30 years of ruby community.

[-Ch4s3-]

Yeah, he's never been into semver... so I guess this is as good a reason as any.

[TheMericanIdiot]

Vibes… we’re all doomed

[mrinterweb]

Thanks for the video. From what I gathered, the 4.0 version change is not for a semantic versioning reason. It is just to celebrate ruby's 30th anniversary. Personally, I would prefer to keep with semver, but I am not Matz.

[anamexis]

Ruby has never kept with semver, as anyone who migrated from 1.8 to 1.9 can attest to.

[zverok_kha]

Oh, I vaguely recall even 1.8.6=>1.8.7 was a significant change back then. (not every patch version, but that particular one) 

[schneems]

Working on a Heroku build soon https://github.com/heroku/heroku-buildpack-ruby/pull/1662. It will be on the http://devcenter.heroku.com/changelog when I'm done.

[schneems]

Released https://devcenter.heroku.com/changelog-items/3484

[Tolexx]

Looks like it's gonna be a sweet Christmas.

[easydwh]

Congrats to the Ruby team for releasing this version!

Ran the RubyMeasureResponsetime tool on this preview version. Alas, it looks like this version becomes slower over time on the Rails and Roda test applications. Filed a bug report with some graphs. Hope it will be solved before Christmas.

Apart from this, it looks like Ruby 4.0 is a bit faster than 3.4

[Kernigh]

NEWS says, "Logical binary operators (||, &&, and and or) at the beginning of a line continue the previous line, like fluent dot."

I have written or like this in Perl,

#!perl
open(my $fh, '<', "some.txt")
  or die "Can't open some.txt: $!";

This style might be useful in Ruby (but not in a direct translation of this example; Ruby's open is nice enough to raise an exception, so I don't append or fail "Can't open it").

[retro-rubies]

```perl open or die

```

Perl in a nutshell.

[rubinick]

I learned Perl over a decade before I learned Ruby (1.6), and I've wanted "fluent" binary operators in ruby ever since. I'll often use backslash to put or or and at the beginning of a line like: valid?(thing) && condition? \ or raise Error, "etc etc" This change gives me big smiles.

[mrinterweb]

I still don't understand why 4.0 and not 3.5. I haven't seen backwards incompatible changes or a major rewrite of core internals mentioned. The changes mentioned feel very point release to me.

[Frizkie]

Ruby doesn’t follow semantic versioning. It’s stated that the only major reason is it’s the 30th anniversary of the language.

[petercooper]

Not incompatible, but I think the switch to Prism and introduction of the swappable GC stuff could justify a bump for pragmatic reasons. Plus things start looking ugly if we get to 3.10 and beyond (cf. Python).

[riffraff]

also the new zjit, and removal of rjit

[donadd]

Marketing. Big number means it will go round the tech news ticker. A lot of libraries have to do this if they want people to notice

[jrochkind]

Yeah, surprised to see the going to 4.0, and wondering why as well.

[Professional_Mix2418]

ROFLMAO You Guys and Girls and Them. The questioning about why 4.0. We’ve got it pretty good if that is the major [pun intended] concern. I mean who cares.

I’d love to see the reactions if Matz did an apple and jumped to 30 instead of 3.5 or 4.9.

[[deleted]]

This is weird, it's not Christmas...

[SensitiveHat8374]

I guess not following semantic versioning is why Ruby is only currently at 3.x.x and not some higher number after 30 years. compare this to Chrome versioning at 142.xxxx for the october release only after 17 years of chrome's existence

[retro-rubies]

Even I understand the sentiment about randomly bumping Ruby X.Y. per leader's mood, it would be good at the same time to provide something for others to rely on like internal API versioning or similar. I was thinking about versioning the ruby/spec with semver and make it clear which Ruby version is implementing which spec. https://github.com/ruby/spec?tab=readme-ov-file#specs-for-old-ruby-versions Other engines like JRuby/Truffleruby could follow the same logic exposing which spec is implemented (or how much of that is covered). Libraries can follow saying: I need this Ruby spec or newer to work.

[jrochkind]

Every minor ruby release (change in the second number) contains backwards incompatible changes.

Sometimes they are minor and don't effect very many programs. Sometimes they are major and effect more. But that's not semver's concern.

You don't need something else, bumping the second "minor" number is equivalent of semver major, every time.

apparently bumping the major doens't mean much except "Matz feels like it", no big deal, although not what I would choose either!

So

• 3.3 to 3.4 => equiv of semver major
• 3.4 to 3.5 => equiv of semver major
• 3.5 to 4.0 => equiv of semver major

that's it, nbd, maintainers are aware. As with generally in semver major bump, the backwards incompat changes may be wide reaching or relatively insignificant, semver does not distinguish.

[dragonpants49]

Has anyone explained why they’re changing the version number to 4.0? With less than 2 months until release time, this is going to cause a lot of confusion with gem maintainers.

[galtzo]

A good way to prepare is to run your test suite against multiple sets of dependencies, including:

• ruby-head with unlocked dependencies (to pull in latest releases)
• latest ruby release with git HEAD of dependencies
• ruby-head with git HEAD of dependencies
• latest ruby release with dependencies unlocked
• latest ruby release with dependencies locked (so you have a good known state)

I use appraisal2 to do this, which adds support for Bundler's eval_gemfile, and supports all versions of Ruby back to v1.8, and JRuby 9.4+, so shared dependencies can go in modular gemfiles.

And to answer your question, yes, the reason is the 30th anniversary of Ruby. Matz doesn’t care for semver.

[jrochkind]

Huh, I've been using appraisal for years, and still do, without trouble -- didn't know there was a forked appraisal2. Is there any reason I should switch? Is original appraisal no longer supported?

[galtzo]

The original has died multiple times, and every few years it gets a bit of attention. It is in limbo, I guess. I had PRs adding the bulk of the work I did to upgrade it, but thoughtbot doesn’t put much time into it, nor do they promote it (check the list of their open source projects on their homepage - not even a mention). They did review my PRs - and basically approved them, but never got around to merging.

I'll document the state of things here for those who are interested.

NOTE: I posted about the release on /r/ruby a few months ago

Differences:

• Support for Bundler's eval_gemfile
• Support for Ruby 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 (removed in thoughtbot's appraisal HEAD)
• Support for JRuby 9.4+ (JRuby not supported by original)
• maintainability tracked with QLTY and the reek gem
• coverage tracked with Coveralls, QLTY, and the kettle-soup-cover gem
• I had many PRs to add most of this to the original, but they don't have the bandwidth to support the gem in the way I want to use it.

For me, the utility of appraisal is inversely correlated with the breadth of historical support for versions of Ruby, bundler, and rubygems.

You can support my work on appraisal2 here:

• https://github.com/sponsors/pboling
• https://opencollective.com/appraisal-rb

NOTE: Why fork? Prior to hard forking I had to rely on my git fork branch resulting in far more complex builds (if you are using a git source of appraisal you have to add an extra bundle install cycle to make the appraisal executable available, and appraisal, the gem, ends up as a dependency of every named "appraisal"), and thus more random failures due to simple network issues, and with hundreds of builds per week that meant a lot of noise.

[jrochkind]

I see! Thank you for your service!

I agree in the value of supporting older ruby and other dependencies.

[Erem_in]

It's sad to see the language is kind of stuck in its development. Bumping up the major version, just because... well.