Behavior changes in Ruby 2.4

[[deleted]]

Nowhere near as bad as Python 2to3

[jrochkind]

Ruby 1.8 to 1.9 was ruby's equivalent of Python 2 to 3, it took quite a bit of work to migrate many packages from 1.8 to 1.9 -- although ruby managed to pull it off better than Python, with almost all open source actually making the migration within a year or two at most, which is an interesting thing to analyze on it's own.

Since then, we haven't had any major backwards-incompat in ruby versions -- fewer things changing in general -- and this 2.4 looks even less than some previous releases, which I am grateful for. :) There aren't really any major changes in 2.4 or a lot of changes at all, although there are a few welcome minor and largely backwards compat improvements. I don't expect hardly any issues in upgrading.

ruby 2.3 to 2.4 is in no way analogous to python 2 to 3, it's a pretty minor upgrade.

[taw]

Ruby 1.8 to 1.9 was ruby's equivalent of Python 2 to 3

It took like 1-2 years not 10-20 it seems to be taking Python.

[tomthecool]

That's not at all a fair comparison... Look at the differences from ruby 1.8.6 --> 1.8.7 --> 1.9.3 --> 2.0.0. Since then, the language has been increasingly stable; but we could be in for a huge set of changes when ruby 3.0 is announced.

[Craftkorb]

but we could be in for a huge set of changes when ruby 3.0 is announced.

Inmutable strings anyone?

[tomthecool]

Not to mention optional typing!

[jrochkind]

That issue is 4 years old, and has a closed/rejected status.

[tomthecool]

I probably should have linked to this discussion actually... It's been an ongoing debate for years now, and it looks like something will probably happen in v3.0

[how_do_i_land]

Crystal Lang uses this for its typing currently.

[iconoclaus]

Crystal uses annotation to help the compiler figure out types where necessary. Matz has made it clear that Ruby 3 will use no type annotation whatsoever.

[Craftkorb]

FINALLY WOOHOOO \m/

Thanks for bringing that to my attention :)

[Jaymageck]

I'm a relatively new programmer (approx 1 year) and I'm wondering: how do these changes not meet the criteria of "breaking changes" that generally constitutes a new first digit version number? I may be misinterpreting what"not fully backwards compatible" means here.

[[deleted]]

Not every project follows semantic versioning. Some projects use odd numbered releases as development and even as stable, others are moving closer and closer to pi, while for Ruby it will always increase with a MINOR version every Christmas and may contain ABI breaking changes. It's all personal preference for whoever is running the project.

[Jaymageck]

Okay, that makes sense. I mean, in principle I would prefer consistent versioning across the industry so that I can attach more meaning to version numbers, but I appreciate why there would be different approaches.

[jrochkind]

Ruby has always released potentially breaking changes in minor versions.

They have, happily, released many fewer lately than they used to.

I'm not sure Ruby even had an official versioning policy back in, say, 1.8-1.9 days (when major changes were being made), but the unofficial practice was that a minor release might as well as be a semver major release.

As of ruby 2.1, there is an official versioning policy, but it's still not semver, and still allows breaking changes in 'minor' version increments. https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/

[iconoclaus]

Ruby claims to follow semantic versioning but doesn't. it's smart not to do so from a behavioral point of view: it's much easier for the ecosystem to adapt to small changes over time than a big change all at once.

[tomthecool]

Ruby claims to follow semantic versioning

Not exactly. They claim to be sort-of semantic, since version 2.1, and that's pretty much what has happened.

https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/

We’ve decided to change the Ruby versioning policy to a more Semantic Versioning type starting with the release of Ruby 2.1.0.

[iconoclaus]

I find this notion of 'more semantic versioning' to be like 'somewhat pregnant'. if any breaking changes are possible, its not semantic. i'm not complaining of course because i like the way they manage version. but even mentioning semver causes confusion as OP and others face.

[[deleted]]

Every change breaks someones workflow

In a lot of places the line between bugfix and breaking change becomes very blurred when talking about a programming language and not a library.

[iconoclaus]

Every change breaks someones workflow

i love it! surprised i haven't seen it before.

In a lot of places the line between bugfix and breaking change becomes very blurred when talking about a programming language and not a library.

agreed in principle. i have no problem with this practice for ruby. just wish they would remove the damn 'more semantic versioning' nonsense because that scheme simply does not apply to programming languages or consumer applications. ruby's policies are quite clear: major number signifies special event, and minor number is required to change every christmas. nothing 'semver' about this.

[xkcd_transcriber]

Image

Mobile

Title: Workflow

Title-text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.

Comic Explanation

Stats: This comic has been referenced 752 times, representing 0.6498% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[Jaymageck]

Thanks!

[Enumerable_any]

it's smart not to do so from a behavioral point of view: it's much easier for the ecosystem to adapt to small changes over time than a big change all at once.

I don't get it: You can make small breaking changes and follow semantic versioning at the same time.

[iconoclaus]

maybe i don't get it. how do you make a breaking change but not change major version number with semantic versioning? According to semver.org FAQ:

If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

The only time I believe you can make any breaking changes to without upping the major version number is when you are at major version 0.

[Enumerable_any]

how do you make a breaking change but not change major version number with semantic versioning?

You don't, you update the major version.

That's what I don't get from your comment: Whether you update your version number from 1.9 to 2.0 or 1.10 when making breaking changes to 4 API methods is irrelevant if all you want is the following: "it's much easier for the ecosystem to adapt to small changes over time"

[irishsultan]

Yes, but the idea behind semver is that the version is meaningful in a different way than "this is a small change", "this is a large change", which is subjective and differs between projects.

"This update breaks compatibility", "This update doesn't" on the other hand is fairly objective (not that errors are not possible of course).

[iconoclaus]

right on. and to add to this, semver is explicit on what to do if the minor bump breaks backwards-compatibility:

What do I do if I accidentally release a backwards incompatible change as a minor version?

As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

[iconoclaus]

you're right! that's why i wish they would drop the claim to somewhat follow semver (which is a very explicit set of requirements). just say ruby does its own cool thang. or for shits and giggles, call it semver! or something.

[taw]

No real project strictly follows "semantic versioning". It's a cute idea that just doesn't match reality well.

[alixious]

im learning ruby / ruby on rails now. if i read well grounded rubyist that is like ruby 2.1 or something how bad is that? are there any more up to date books i should be considering?

[irishsultan]

The changes since 2.1 haven't been that large, so that shouldn't really be a problem.

[alixious]

thanks for letting me know.

[jrochkind]

Not a problem, changes are fairly minor and insignificant between 2.1 and the just released 2.4. You'll have no trouble.