Which is quite ironic, because (at least from my experience) Ruby constantly breaks backward compatibility.

Not at all, I can easily migrate 1.9 Ruby projects to 2.2.3 w/o any problems.

I remember that code for Ruby 1.8 required changes in source to make it run on Ruby 1.9 and that was just a minor version change.

When was your experience? I could definitely agree with that pre 1.9.x. But I can think of barely a handful of examples in which minor things have broken during my time in Ruby from 1.9.3 to 2.1.5...even when booting up a year-old laptop with godknows what actual version of Ruby via rbenv I have on it...things just seem to work...And even problems that arise from specific scenarios with libraries, or when I simply must move an old system from 2.0 to 2.1.x or whatever...Upgrading the Ruby and then running bundler almost always just works.

In contrast, with Python, on a weekly basis I run into 2.x and 3.x problems...last week it was running the Google Cloud SDK, which is 2.x only. I say this as someone who has almost switched exclusively to Python (3.x) and enjoy it...but man I miss the days of Ruby's ease-of-use.

(but yeah, 1.8 to 1.9 was not a lot of fun, but thankfully, many years have passed since then)

Yes, it was 1.8 to 1.9 and frustrating because the change was just increase in minor version number.

It's not necessarily about breaking or maintaining backward compatibility that matters here. It's about how supporting two similar looking yet ultimately incompatible versions creates confusion for new users, driving them away.

This is the same issue facing Perl (although the Perl situation seems more dire) WRT Perl 5 vs Perl 6. For Python maybe the benefits of keeping Python 2 alive for large users offsets the harm of any confusion, I have small projects (all in Python 3) so it's a rare annoyance rather than a deal breaker.

> This is the same issue facing Perl (although the Perl situation seems more dire) WRT Perl 5 vs Perl 6.

The situation with Perl is neither more dire nor really the same issue as with Python. Perl 5 is not going away. Perl 6 maintainers are not the same people as Perl 5 Porters -- both will be maintained for the foreseeable future.

Second, Perl 6 is a significant change to Perl, with far more features and somewhat different syntax. People will want to change for the features. Running Perl 5 code from inside Perl 6 works by calling out to libperl, which runs a real version of Perl 5. Perl 5 will still be popular due to ubiquity, access to CPAN modules, and things like CPAN Testers.

So it's a choice for the developer, to develop in a new language that just happens to be Perl-flavored, or to go with any other language. Not really a crisis.

I agree, I think they should simply deprecate Py2 instead dragging it for 7 years + 4 more planned. People would start migrating if they knew that Py2 would be EOL soon and instead of Py2 or Py3 would be whether you want your code to run in the future and make sure all security bugs are fixed.