Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible).
PHP made an backwards incompatible change in their code so it should have been a major version increase.
So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver.
Is that not your opinion?
In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once.
Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did.
Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different.
Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport.
And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.)
Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit.
Ruby is a bad example.
Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.
The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.
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.
Well played, sir.
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.
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.
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.
{"a", "b"}
String class was also given a nice kick in the ass, at least in regards to iteration.
Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better.
- Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way
As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.
However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..
I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.
Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts.
> That's just a dumb thing to do in any language.
Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.
php> echo "2coolforschool" + 1;
3
php> echo "2.1coolforschool" + 1;
3.1
php> echo "coolforschool" + 1;
1
So treating all kinds of garbage as valid numbers is absolutely part of PHP.
Do the stupidest thing that could possibly work; and it probably will. For now.
Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.