When should I drop support for python2.4 on my public python library?

Question

I maintain an open source python project. Right now it supports python 2.4, 2.5, 2.6. I am looking for to add support for python 3. I guess it will be easier if I drop 2.4 support.

I know it is possible to support all but it is very annoying if I have to install 4 or 5 python versions on my machine and run the tests on all of them. Although it is easy to avoid new features introduced in the language I would like to make use of them! And what is the point of supporting something that possible nobody uses? I do want to drop it, but also dont want to loose users (existing and new).

When should I drop support for python 2.4? Is there any recommendation on this?

Answer 1

It's a matter of weighing pros and cons.

I suppose the real answer to this question is how many features there are in 2.5/2.6 that would really improve your library. It seems as though 2.4 becomes less and less worth supporting as time goes by.

On the other hand, there are still some people on Python 2.4. You have to decide if it's worth it to drop support for them to take advantage of newer features of Python 2.5.

Answer 2

I'd say it depends on your target audience. For enterprise stuff I think RedHat (certainly CentOS 5) are still on 2.4 - so if you want typical RedHat/CentOS using people to able to install without resorting to third party python installations then I think you need to keep 2.4 for a while. If most of your users are more 'desktop' based running Fedora/Ubuntu then they probably have 2.5/2.6 already so it wouldn't be an issue for them.

Answer 3

You don't have to drop support for 2.4 in order to add support for 3.x, as I'm sure you know. I've made coverage.py run on 2.3 through 3.1 with the same code. It's not always pretty, but it's possible: Running the same code on Python 2.x and 3.x.

Answer 4

Any answer here is going to be subjective. I suggest you make a feature and user list. There are 2 things to consider here.

1: How will your program benefit - what features are better nicer/faster/less buggy in newer versions of Python ? What extra dependent libraries can your program utilize by sticking to an older version ? Not everything is ported to 3.x or even 2.5 yet.

2: How will your user benefit - What benefits do users gain from older versions. How much bigger / smaller does your user base get by dropping 2.4 and adding 3.x ? What does your user base look like currently.

The third is not really a point since direct benefit from Open Source to developers is kinda iffy - but what do you gain ? i.e. less time needed to maintain, faster development etc.

Hope making a summary will help you put things in perspective.

Answer 5

You don't have to drop anything, what works on 2.4, works on 2.5 and 2.6. You can easily avoid incompatibilities skipping "with", the ternary operation, et "import future".

Now, once you have a very stable and full featured version of your code and need to make a big achitectural change, start writting for Python 3.0. No rush, it won't be massively used before one year or two.

A good indicator is to focus on project that have the same audience as yours. When do they switch on the roadmap ?

• GNOME ?
• Django ?
• Inkscape ?

Answer 6

Track downloads of each version of your project. Graph the daily traffic (or weekly if there is too much variation day to day) for each version separately. Keep an eye on the trends and at some point you will see a distinctly downward trend for 2.4 compared to the rest. When that downward trend is well established, discontinue upgrades to the 2.4 version, but keep it available for download. You should include some kind of note in the README for the last 2.4 version, and maybe display a message when it is installed.

At this point, your work is done, unless you find some really glaring error that you want to fix. You don't ever have to actually discontinue the 2.4 version, just cease upgrading it.

And the graphs that you now produce every week will tell you when it is time to do the same for 2.5, and eventually 2.6.