Perl never had a problem (at least with the Perl 5 and Perl 6 distinction) besides marketing. No one has ever been confused why their perl script doesn't work because their perl was version 6 instead of 5, and they never will be. No one has ever had worry about having writing a perl program to be compatible with both, unlike python where you never know if "/usr/bin/python" is 2 or 3.

Marketing is important. I did have people ask me if there was any point to learning Perl 5 when Perl 6 was just around the corner, and people buying the butterfly book instead of the llama book for the same reason.

Then the Python people did the same mistake. Beginners learned Python 3 and then had trouble with App Engine or some other platform. The most popular question in Python forums for many years was if someone should learn 2 or 3. Some probably just went with Go instead.

In some fields, Python is embedded as an interpreter into major binary platforms or commercial apps.

So in many of these cases the end user doesn't have a choice to use Python 3 until it's on offer.

And the vendor has usually integrated Python at a binary level into C code; that's why they provide a Python API.

The answer could even be "Red Hat Enterprise Linux 6"; consider that Python 2 is the default in this OS, which ended official support only at the end of last year. Many enterprises _chose_ this platform for its longevity, along with 3rd party vendors of commercial software.

Likely a key factor is leaving support for the old version. If they had immediately deprecated python 2, users would have quickly updated their packages over to a supported version.

>>> If they had immediately deprecated python 2, users would have quickly updated their packages over to a supported version.

Painfully wrong. They tried to deprecate at least twice, it was so bad a decision that they had to backtrack.

In fact Python 3 is the hard proof that you cannot hope users to upgrade, by abandoning ship and giving no way to upgrade.

Well there is a way to upgrade. They even provided an automated tool that would convert code and warn you about the handful of changes.

Somehow it feels like PHP being a synonym to WordPress and Node going though babel makes these languages different too from perl and python too.

Node 0.12, Java 6 and 8, PHP 4 - there's been plenty of examples of "sticky" versions in the past that had to be pushed away for other languages

Java and PHP I could see as being similar to the Python as they all shared the pain of widespread adoption by vendors that were reluctant to update (Java: enterprise organisational internal, PHP4: bad cheap webhosts, Python2: everyone?).

With Node 0.12 though I don't see it. IOJS was a pretty momentary internal political issue that many users didn't even register on their radars. It certainly didn't have any long-lived impact on version adoption within the community.

And: the important point, they've all had very successful major bumps since. So even if there are pains, they can be overcome. There's nothing fundamentally un-doable about major version releases for open-source languages.

A better comparison would be to Typescript which is a breaking change from JS but is branded differently. I'd love native typescript in the browser but browser vendors aren't going to go pushing a massive breaking change like that.

PHP had, never heard of php6?

PHP6, similar to ES4/ESX, was a language version that ended up in spec. hell. Nothing to do with release woes (none were ever released), so I don't see any real relevance in this discussion?

PHP7 on the other hand was a pretty seamless migration from PHP5, and PHP8 looks likely to be similar.

General point is the original commenter was posing this as some fundamental issue of open source languages: clearly there's plenty of examples of success, so it can't be.

Php6 also had a codebase. They tried something Similar as python 3 , well they stopped it and backported stuff like intl.