I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on.

The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.

None of the decisions listed here were "obscure" design decisions and none of your examples indicates that ruby is unstable.

Specifying the source encoding in 1.9 is only required if you have string literals in your code that are not in the default encoding. That should be a rather rare case, in fact pretty much none of my code files has the encoding header. Ruby 1.8 was not encoding aware, so Strings were just pure byte streams and the encoding didn't matter.

Changing the way require works fixed a potential attack against ruby scripts. Effectively the only thing that was changed was that from that point on the working directory was not included in the loadpath any more. Calling `ruby -I . <script>` reverts to the previous behavior. Backporting require_relative is not a sensible decision, 1.8 has reached EOL. If you need to write code that compatible to both ruby versions, just don't use it. It's nothing but a convenience method (in fact, most libraries just use a proper LOAD_PATH setup and don't use it). Since 1.9.2 was the first stable release of the 1.9. branch it's fair enough at that point.

Breaking the extension API between 1.8 and 1.9 is fair enough as well since Ruby 1.9 is a new major release. Ruby's versioning works different than PHPs. A minor PHP release (5.3.1 -> 5.3.2) would be a patch release in ruby (1.9.3-p0 -> 1.9.3-p125). Breaking changes are required at some point. 1.9 added more breaking changes, such as String not being enumerable any more etc. Most of those were required to add encoding support, which was the big and important feature added at that time.

All in all I must say that the only large-scale breakage of existing code I've witnessed in the ruby world was the 1.8 -> 1.9 transition.

So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about.

Well played, sir.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions".

All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had code that's hard to change or adapt. Hey, one of the examples the OP posted is "we had code relying on an obvious parser bug, and it breaks since they fixed it." So well, call it "dismiss" if you want. I call it "evolving a language"

I've been working with ruby at the point when 1.8 moved to 1.9 and it was quite a change. Pretty much every library that handled strings broke, but I don't see any way around that and still get encoding support. Many people actually forget that ruby 1.9 is actually what should have become 2.0.

I've been affected and patched several libs to work properly with 1.9.[1] There's absolutely no reason to become snarky.

[1] most of the changes required were trivial, still it's breaking and annoying.

Fair enough, I apologize for the snark, but then everything you've said hinges on your interpretation of the word "obscure".

Looking at the sibling comment, I'll happily take back the word "obscure" if it sounds too negative and subjective. But I stand by my opinion that Ruby is unstable because most of the above changes could have been handled in a backwards compatible way (for non-pathological cases). That should-be 2.0 was turned into 1.9 does not help :)

Not that stability is always the right choice, I wish C++0x would have been more radical, for example. It does matter for long-lived codebases though.

Well, 1.9 was the "unstable" branch leading up to 2.0, that's why that actually matters. And that's why most of those changes were made at that point - they were intended to land in 2.0. Later the decision was made to roll 1.9 as a stable release since 2.0 would take another couple of years and encoding support was an important feature that people wanted to ship. So a lot of changes that could not be handled in a BW-Compatible way landed in 1.9 since encoding support required those changes. String all of sudden was not enumerable any more since there was now String#each_byte and String#each_char which did something different. Require was changed because loadable encodings were an attack vector, ... But for people that needed the old behavior 1.8 was supported until lately and REE (1.8 patched) is still supported.

The breakage in 1.8.6/1.8.7 was widely regarded as a massive failure on the maintainer side - a bugfix for a security vulnerability that had other changes land in the release (and subsequently segfaulted, sigh). That's however not a design change. Something like that has never happened ever since.

I actually agree with you up to a certain point: The ruby ecosystem is was and still is pretty unstable. Things have settled a little lately, but gems still appear and disappear, are superseeded by newer versions or other gems that do things differently. That's good in some ways, since stuff evolves and improves, bad in other ways - the lib you depend on just disappears or falls out of maintenance. However, none of this is the core-languages fault. Behavior of ruby as a language has been pretty stable during the last couple of years.

Hahaha. People wouldn't complain. That's a knee slapper.

No more preposterous than software without bugs.

At that point I'd start making fun of your username ;)