how long to support Python 3.3?

[Tim Graham]

Django 1.8 was the last version to support Python 3.2, which has its security updates end February 2016. That means Python 3.2 users can continue getting Django security updates for about 2 years after Python security updates end. I am wondering if we should instead try to better align the end of Python support with the end of Django support? (By the way, Django 1.4 supports Python 2.5 which had its security updates end Oct 2011 and since we had trouble configuring Jenkins with Python 2.5, we broke compatibility a couple times in recent security releases -- now I run the tests locally as needed).

Let's take Python 3.3 as an example. Security updates for Python 3.3 are scheduled to end in September 2017. Django 1.8 supports 3.3 and will receive updates until April 2018. Given anyone using 3.3 is covered by the LTS, I'm inclined to drop 3.3 support now (in Django 1.9). Alternatively, the next two major releases of Django will be supported until April 2017 and December 2017.

I don't find Django support for 3.3 to be a big burden, but there are occasional issues such as new features in 3.4 that are missing and need to be backported for 3.3 (today I ran into a pull request with a need for glob.escape(), so we needed a backport that works on Python 2 and Python 3.3). The other consideration is that Python 3.5 will be released in September, so we'd be back to 3 versions of Python 3 for Jenkins to test against.

Are there any users of Python 3.3 out there who find that there are big obstacles to upgrading to 3.4?

I think it's useful to plan ahead a bit to try to avoid cases such as the enterprise users who are now stuck on Python 2.6 and Django 1.6.

[Collin Anderson]

Some more data points (to support removing 3.3 support):

I believe old versions of RHEL were the reason people needed 2.6 support. Unlike 2.6, I believe RHEL has never supported Python 3 except through "Software Collections", and the Python33 software collection EOL is Oct 2016 (before 1.8 support ends). There is also now a Python 3.4 software collection.

https://access.redhat.com/support/policy/updates/rhscl

Looking at recent PyPI data gathered by Donald: https://caremad.io/2015/04/a-year-of-pypi-downloads/

It looks like 3.3 has less usage than Python2.6 in the Django world.

https://caremad.io/images/a-year-of-pypi-downloads/django-stacked-py-pct.png

(It also looks like 3.x usage has more than doubled over the last year. :)

[Tim Graham]

Here are the cleanups for dropping Python 3.3: https://github.com/django/django/pull/4861

To prevent users from getting stuck on a non-LTS version of Django with an old version of Python (when they would have had longer support had they stuck with an LTS), the policy I suggest we adopt is:

Typically, we will support a Python version up to and including the first
Django LTS release that will receive security updates until after security
support for that version of Python ends. For example, Python 3.3 security
support ends September 2017 and Django 1.8 LTS security support ends April
2018. Therefore Django 1.8 is the last version to support Python 3.3.

[Carl Meyer]

On Monday, June 15, 2015 at 7:49:32 AM UTC-6, Tim Graham wrote:

Here are the cleanups for dropping Python 3.3: https://github.com/django/django/pull/4861

To prevent users from getting stuck on a non-LTS version of Django with an old version of Python (when they would have had longer support had they stuck with an LTS), the policy I suggest we adopt is:

Typically, we will support a Python version up to and including the first
Django LTS release that will receive security updates until after security
support for that version of Python ends. For example, Python 3.3 security
support ends September 2017 and Django 1.8 LTS security support ends April
2018. Therefore Django 1.8 is the last version to support Python 3.3.

I think this policy makes sense. It aligns nicely with the direction the new releases policy is heading, which is that the release right after an LTS is the one where more backwards-incompatible changes tend to concentrate (and the one where we bump the major version number).

Carl