Gregory Szorc recently wrote a laundry list of reasons for ditching support for old Python releases. I think this list of reasons to upgrade misses the larger point in providing software for other people: You do not get to tell your users what to do.
Maybe those users don’t have sufficient control over their working environments to install a new version of Python. (Webhosts and university computers are the two examples that spring to mind immediately. Enterprise environments have similar constraints.) Maybe those users rely on certain APIs only available in older versions of Python and don’t wish to take an indeterminate amount of time to rewrite (retest, recertify, etc. etc.) their software. Maybe those users rely on certain APIs that were changed to operate differently in newer releases and don’t want to engage in an extensive audit of their codebase to fix those incompatibilities. Maybe those users are using other packages that are incompatible with later Python releases and cannot upgrade. Maybe those users are just rationally lazy and don’t want to deal with downloading, configuring, and installing a new version of Python, plus dealing with inevitable fallout, when the old version has worked Just Fine for everything else. The list goes on and on. (Of course, these reasons are not applicable to just Python; feel free to substitute your favorite language X or favorite extensible program X or what have you.)
Microsoft is the best example I can think of for backwards compatibility. New Windows releases have gone to significant lengths to make it possible to run applications for older versions of Windows, whatever faults those applications may have. Raymond Chen’s blog documents a number of extraordinary things Windows does under the hood to make outright buggy and/or undocumented-internals-groveling programs that worked under previous versions of Windows still work under newer ones. You can, of course, argue that this has taken significant engineering effort that could have been put to use doing “better” things. But Microsoft’s evaluation of “better” clearly includes “how much pain will this inflict on our customers?”
And that’s the point: you are trading off some perceived (and make no mistake, it is perceived) benefit to yourself as a developer of software X against the agony of some unknown number of users as your changes break their world. Maybe you’ve decided that this agony is small enough: I’ve seen some great examples of this from the DOM/Content folks as they install Telemetry probes to measure how many users might be impacted by backwards-incompatible changes. Maybe you’ve decided that you have a small enough community of users and they are all enthusiastic enough to adopt whatever you decided to do, even if it breaks things. (You might be surprised at just how “small” your community is, though.) Maybe you’ve decided that ditching the old stuff really is necessary and appropriate (hi Australis!). Maybe you’ve decided that you simply don’t care about the agony of your users, or that the sharp spike in curses uttered against your household don’t matter. (If you take this last approach, please don’t write any software that I use.)
I realize that using the new shiny stuff in Python, or C++, or whatever generally makes life nicer as a developer. But I think developers tend (myself included) to systematically underestimate the amount of agony that user-facing changes cause. Even when we know we are prone to doing so.