| Does it make sense to you that if there is a breaking change between 1.9.1 and 1.9.2, then there is a breaking change between 1.9.1 and 1.9.3? I'm just stating my (local) experience; I don't have a global god's-eye view of ruby.
I'm not an expert in ruby; I'm just trying to get started. You seem to expect a beginner to know exactly which versions introduce a breaking change, and to read the release notes in detail - and understand them, which is difficult for someone who has not yet learnt ruby or its terminology. When you start to have categories of breakage, as "major" or not, and defend porting code between versions as "not much work", it means you accept some breakage as normal. To me, a breaking change is one that causes code to stop working, and require extra labour. Python and Java don't do this (nor Windows, x86 or ARM). Note that from 1.9.1 to 1.9.2 is not a major release. It's not even a point release. It's a point-point release with "major" breaking changes (according to you). As I carefully said, this is a consequence of constant improvement (contrast with Java, c#, x86). (guessing: do you think it's partly due to the power of ruby making security harder?). The trade-off doesn't suit beginners. Note that back-compatibility is a "successful programming language problem" - no one complains if a toy language breaks. I'm just drawing attention to the downsides, because if uncorrected, in the long-term, it may lose the next generation of coders. Look, I'm not out to attack Ruby; I like ruby. But this is a real problem. Disregarding it is a disservice to ruby. |