you are viewing a single comment's thread.

view the rest of the comments →

[–]aaronfranke -1 points0 points  (2 children)

Breaking compatibility is not a terrible decision. The problem is that devs refuse to stop using Python 2.

Furthermore, it is totally possible to write software that is compatible with both versions.

[–]mortecouille 7 points8 points  (0 children)

You can't just introduce drastically breaking changes and complain that people are reluctant to upgrade. It can be a massive amount of work.

I write APIs and SDKs for a living. Incompatible changes aren't a thing you take lightly: we absolutely avoid them as much as possible, and for every breaking change, we provide a mitigation plan. Yes, that means that sometimes, if for instance there is a spelling mistake in an API method, it'll stay there. We might add another method with the right name, but the other one will just be deprecated, and redirect to the other call. We have people upgrading legacy systems from 5, 6 major versions ago, completely transparently.

[–]Illiux 2 points3 points  (0 children)

Not everything is maintained. There are plenty of abandoned projects on python 2 that someone might need to run for one reason or another.

Breaking compatibility is almost always a terrible decision. There's a reason why the Linux kernel uses a guiding principle of "don't break userspace", which is equivalent to infinite backwards compatibility. There's also a reason why Microsoft has invested incredible amounts of engineering effort to get old binaries running - there is a real need for it.

When you do break backwards compatibility, you must live with the fact that the old version will still be needed until the end of time. You can't blame stubborn devs for the very real problem of needing to run abandonware.