on old releases

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.


  1. Then those people should use old versions of the library, not the new ones. The rule that I follow is that I don’t support my code on platforms or with dependencies that don’t provide more support either. To continue the support on old version of Python, Java, Ruby, etc., is to encourage people to continue using deprecated and insecure platforms. If you are already failing to have your platform on a supported level, don’t ask me for support of new features, Use older releases that were supported on those platforms

  2. Arpad Borsos

    Still, there is a big difference between “user” and “developer”. While of course devs are also users, the point of updating a build time dependency is not “user-facing” IMO.

    And honestly, if developers are too “lazy” to update their system, they should just stop developing altogether.

    Also, the case with “can’t use” for environments not under the users control also comes down to lazyness. In that case its good to indirectly put some pressure on the sysadmins of such webhosts, universities and corporations. The sooner the better, or else I will be one of the first to point fingers and laugh with an “I told you so” when their systems will be exploited using some long fixed vulnerabilities.

    We are not living in an ideal world and there is a lot of lazyness out there, that’s why we need to create pressure (and incentive) to get active. Otherwise we would all still be surfing the web with IE4 and Win98.

    • Nathan Froyd

      This assumption that “lazy” developers who don’t update their systems are somehow not competent and/or that we should just disregard users/developers in corporate/university/webhost environments, even laugh at the sysadmins (and indirectly, the users) get pwned, is exactly the sort of assumption that motivated this post.

      • Arpad Borsos

        The thing is: I’m as lazy as they come 🙂
        And *because* I’m so lazy, I don’t want to spend all that time to backport things and to keep them working on old versions which is a real hassle.
        It’s far less painful to just be up to date. One more reason I switched to a rolling release distro, I simply don’t have to worry about not having an outdated package lagging behind upstream, saves me a lot of time 🙂

        It’s the same as with patches. If you refresh regularly, it is less likely to bitrot. And it saves time in the long run.

        And that attitude is not about “disregarding” users, quite the opposite. Most people just need a little push to improve their situation and profit in the long run.

        • Nathan Froyd

          *shrug* I’m lazy too. That’s why I don’t update my stuff unless I absolutely have to, because what I have right now works. I tried using “rolling release” distros and found stuff was getting broken frequently enough that it wasn’t worth it to try and stay up-to-date.

          I don’t understand how a) having users of some software X with non-negotiable environments along with b) dropping support for said environments in software X is “showing regard” for the users. My sense of things is that you are arguing that the pressure those users put on their administrators to upgrade the environment is beneficial for the users, therefore dropping support is actually doing the right thing for the users. I am sympathetic to that argument, but I don’t think that’s a good position, particularly because the benefit is wildly overestimated and the time lag can be significant. (Similarly, for those environments that *do* get upgraded and things stop working, that is also a failure on the developer’s part.)

  3. With VM’s supporting ‘older’ environments is just a matter of disk space. I can flip between 3 different linux and 4 different windows versions and at least 10 different compiler chains. All from 1 computer. Hassle to setup? Oh yeah. Worth every byte on my HD. Snapshots erase bad mistakes quickly. Duplicating what a customer sees quickly is nice too…