Revisiting Python support for after Django 3.2 LTS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Revisiting Python support for after Django 3.2 LTS

Carlton Gibson-3
Hi all.

The Python version support policy reads [0]: "Typically, we will support a Python version up to and including the first Django LTS release whose security support ends 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."

Updating that to current numbers we have:

Python  EOL         [1]
3.6     2021-12-23
3.7     2023-06-27
3.8     2024-10
3.9     2025-10

Compared with the next two LTS versions for Django

Django  EOL         [2]
3.2     2024-04
4.2     2026-04

By my reckoning this makes Django 3.2 "the first Django LTS release whose security support ends after security support for that version of Python ends" for both Python 3.6 and Python 3.7.

Thus on the current policy we should drop support for both Python 3.6 and Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.

I'm not sure what I think about that. I started writing this thinking just about Python 3.6 — and then I looked up the dates.

I think we should drop Python 3.6 at this time. asyncio is still evolving and there are API changes between 3.6 and 3.7 that I think we need to get the other side of.

I think though that dropping support for Python 3.7 would be a little aggressive — it will still have ≈18months of life at the point Django 4.0 is released.

I've argued previously for a loosening in the policy here[3]. Roughly, unless there are technical reasons to advance, the situation I'd like is that, if you have a (python-)supported version of Python then you can `pip install Django` and get the latest major version. That is, roughly, the ideally, we'd follow Python's support versions policy. (The flip side being I think we should probably be actively dropping support for versions of Python as they go EOL, even if between LTS versions.)

With the change to Python's new annual release cycle[4], we're going to need to adjust the policy somehow. Python 3.8 will be EOL for a full 2 years before Django 4.2 is itself EOL.

Can I ask for consideration and ideas at this stage, which hopefully can lead to a fresh consensus?

Thanks!

Kind regards,
Carlton

[1] https://devguide.python.org/#status-of-python-branches
[2] https://www.djangoproject.com/download/#supported-versions
[3] https://groups.google.com/g/django-developers/c/YDJwI7uvgxU/m/c0ZPHaXZFQAJ
[4] https://www.python.org/dev/peps/pep-0602/

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Jure Erznožnik-2
Maybe I'm getting old, but:

This is going extremely (too?) fast. I don't think Ubuntu LTS releases
provide Python versions in time before the release chosen for the LTS
becomes expired. I've definitely had an issue like this with
django-channels and its required redis version.

So if I choose a few different LTSs for my server deployments, all of
them dropping support so aggressively, I will end up with something
out of date for a good portion of my server lifetime. For example,
Ubuntu 20.04 will be supported until 2025, but it is using python 3.7
which will only be supported until 2023... So if I want to keep
up-to-date, I will have to move to 22.04 as soon as it gets out. Same
with any Django LTS, same with any other thingy LTS. All of that often
requiring custom builds because maybe some other LTS won't be
supporting the new versions yet...

OTOH, the new features are so nice to use...

So, maybe we don't really have to be SO strict dropping support?

LP,
Jure

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson <[hidden email]> wrote:

>
> Hi all.
>
> The Python version support policy reads [0]: "Typically, we will support a Python version up to and including the first Django LTS release whose security support ends 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."
>
> Updating that to current numbers we have:
>
> Python  EOL         [1]
> 3.6     2021-12-23
> 3.7     2023-06-27
> 3.8     2024-10
> 3.9     2025-10
>
> Compared with the next two LTS versions for Django
>
> Django  EOL         [2]
> 3.2     2024-04
> 4.2     2026-04
>
> By my reckoning this makes Django 3.2 "the first Django LTS release whose security support ends after security support for that version of Python ends" for both Python 3.6 and Python 3.7.
>
> Thus on the current policy we should drop support for both Python 3.6 and Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
>
> I'm not sure what I think about that. I started writing this thinking just about Python 3.6 — and then I looked up the dates.
>
> I think we should drop Python 3.6 at this time. asyncio is still evolving and there are API changes between 3.6 and 3.7 that I think we need to get the other side of.
>
> I think though that dropping support for Python 3.7 would be a little aggressive — it will still have ≈18months of life at the point Django 4.0 is released.
>
> I've argued previously for a loosening in the policy here[3]. Roughly, unless there are technical reasons to advance, the situation I'd like is that, if you have a (python-)supported version of Python then you can `pip install Django` and get the latest major version. That is, roughly, the ideally, we'd follow Python's support versions policy. (The flip side being I think we should probably be actively dropping support for versions of Python as they go EOL, even if between LTS versions.)
>
> With the change to Python's new annual release cycle[4], we're going to need to adjust the policy somehow. Python 3.8 will be EOL for a full 2 years before Django 4.2 is itself EOL.
>
> Can I ask for consideration and ideas at this stage, which hopefully can lead to a fresh consensus?
>
> Thanks!
>
> Kind regards,
> Carlton
>
> [0] https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
> [1] https://devguide.python.org/#status-of-python-branches
> [2] https://www.djangoproject.com/download/#supported-versions
> [3] https://groups.google.com/g/django-developers/c/YDJwI7uvgxU/m/c0ZPHaXZFQAJ
> [4] https://www.python.org/dev/peps/pep-0602/
>
> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJ%3D9zieOHxefv%2BpUF%2BT2xch-N%2BWusMeeaFv%3DGzFhHY_LNw%3DfAw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Paolo Melchiorre
In reply to this post by Carlton Gibson-3
Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson <[hidden email]> wrote:
> ...
> Thus on the current policy we should drop support for both Python 3.6 and Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
> ...
> I think we should drop Python 3.6 at this time ...
>
> I think though that dropping support for Python 3.7 would be a little aggressive ...

I agree with you.

Python 3.7 is still the default version in the stable version of
Debian 10 (Buster) with LTS until 2024.

Kind regards,
Paolo
--
Paolo Melchiorre

https://www.paulox.net

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx67iV6ENfs1WF7eGo9qMr%2BAMVpKOOJ9JZ_pwSWfsJeSgg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Andrew Godwin-3
I agree we should not be quite so beholden to our existing Python version policy - that was mostly to get us out of the early 3.x era. Now things are more stable, I'd support a policy that is much more like "any stable version of Python currently out there and supported".

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e1f40b9d-a017-4507-b855-2055713d960e%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Tim Allen
I often hear Ubuntu thrown around during these discussions, and it is my distro of choice for personal projects. But like many of us, I work at a RedHat / CentOS shop, and trying to maintain a current Python version is a much more difficult proposition. Unfortunately, IUS Community has stopped providing yum-installable versions of Python in an attempt to get EPEL to be more up to date, but that hasn't happened. To get a version of Python greater than 3.6 on RedHat / CentOS, AFAIK, you currently must build from source with altinstall.

I agree with Andrew's statement that we should consider each version. I can see dropping Python 3.5 support - it would allow us to use a feature like f-strings, which improves readability and speed throughout the codebase, and is ubiquitous in Python. But what does dropping Python 3.6 support really achieve? Do we need data classes?

I realize there is a need to move forward, especially for wonderful things like better async support. I just ask that we also consider those of us using Django in corporate or academic settings where the pace of upgrading Python is a bit more glacial.

On Thursday, November 19, 2020 at 11:51:29 AM UTC-5 Andrew Godwin wrote:
I agree we should not be quite so beholden to our existing Python version policy - that was mostly to get us out of the early 3.x era. Now things are more stable, I'd support a policy that is much more like "any stable version of Python currently out there and supported".

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/83fc7a73-aa7d-4390-805f-c50c496175f8n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Carlton Gibson-3
Note that this is discussing support in Django 4.0 (which is the main development branch after stable/3.2.x is created).

4.0 will be released December 2021. Python 3.6 is EOL that very month

> 3.6     2021-12-23

The next version of Django (3.2) will support Python 3.6

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/BD6D9F10-C307-4D0D-BDF6-FD1AAB81EEEF%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Ahmmed Sabbir
In reply to this post by Paolo Melchiorre

Hey Paolo,
I'm trying to develop an email testing application with Django. But nowadays I've faced some problems with this application. One of them is, when I taste it myself- it works just fine. But in the case of multiple users, the application gives me back some error code is mentioned "[6996] Child process with pid: 7082 was killed by signal: 15, core dump: 0"
I couldn't find any useful solution anywhere. Let me know if you can find the appropriate solution & and help me out.
On Thursday, November 19, 2020 at 2:50:45 PM UTC+6 [hidden email] wrote:
Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson <[hidden email]> wrote:
> ...
> Thus on the current policy we should drop support for both Python 3.6 and Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
> ...
> I think we should drop Python 3.6 at this time ...
>
> I think though that dropping support for Python 3.7 would be a little aggressive ...

I agree with you.

Python 3.7 is still the default version in the stable version of
Debian 10 (Buster) with LTS until 2024.

Kind regards,
Paolo
--
Paolo Melchiorre

https://www.paulox.net

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c816360d-ee52-4b19-8d5f-f21a1277ab18n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Tim Graham-2
In reply to this post by Carlton Gibson-3
Part of the rationale for dropping Python versions after an LTS is was to avoid getting "stranded" on a non-LTS version of Django. For example, if we keep Python 3.7 support in Django until Python 3.7 is end of life in June 2023, that would probably make Django 4.1 the latest version to support it (4.2 is scheduled for April 2023, a few months before Python 3.7 EOL). At that point, someone stuck on Python 3.7 would receive Django security updates a few months longer if they had stuck with 3.2 LTS (supported until April 2024) compared with Django 4.1 (supported until December 2023). That's not so bad, but if the version following an LTS is the last to support a particular version of Python, like would happen with Django 5.0 and Python 3.8 in my forecast below, then this "Django security gap" for a particular Python version would be one year.

Historically, Django has supported 3-5 version of Python. With Python moving to a yearly release cadence, that's going to increase the number of versions of Python that Django has to support under the current policy to 4-6. Amending the Python version support policy as suggested would mean it would always be 5-6. That makes for some large build matrices. I'm especially thinking about the downstream effects to all the third party apps that follow Django's Python support.

(Incidentally, it occurred to me that more rapid Python releases *might* actually mean that being a little more aggressive in dropping old Python versions from Django might be less disruptive than it was in the past, that's if new Python versions make it out to the distros more quickly. It's probably too soon to tell, but someone who follows distro releases might be able to give a forecast.)

This chart assumes "support a Python version up to the Django release that's a few months before that Python EOL." I didn't proof it super carefully but it should give a general idea of what's coming.
- Stars indicate of version of Python that wouldn't be supported under the current "Typically, we will support a Python version..." guideline.
- Dates in parentheses indicate Python version support added after a major version's initial release.

Django      Released            End of life
2.2 LTS     April 2019          April 2022      3.5, 3.6, 3.7, 3.8, 3.9
3.0         December 2019       April 2021      3.6, 3.7, 3.8, 3.9
3.1         August 2020         December 2021   3.6, 3.7, 3.8, 3.9
3.2 LTS     April 2021          April 2024      3.6, 3.7, 3.8, 3.9, 3.10 (Oct 2021), 3.11 (Oct 2022)
4.0         December 2021       April 2023      3.7*, 3.8, 3.9, 3.10, 3.11 (Oct 2022)
4.1         August 2022         December 2023   3.7*, 3.8, 3.9, 3.10, 3.11 (Oct 2022)
4.2 LTS     April 2023          April 2026      3.8, 3.9, 3.10, 3.11, 3.12 (Oct 2023), 3.13 (Oct 2024)
5.0         December 2023       April 2025      3.8*, 3.9*, 3.10, 3.11, 3.12, 3.13 (Oct 2024)
5.1         August 2024         December 2025   3.9*, 3.10, 3.11, 3.12, 3.13 (Oct 2024)
5.2 LTS     April 2025          April 2028      3.10, 3.11, 3.12, 3.13, 3.14 (Oct 2025), 3.15 (Oct 2026)

Python  Released           End of life
3.5     September 2015     September 2020
3.6     December 2016      December 2021
3.7     June 2018          June 2023
3.8     October 2019       October 2024
3.9     October 2020       October 2025
3.10    October 2021       October 2026
3.11    October 2022       October 2027
3.12    October 2023       October 2028
3.13    October 2024       October 2029
3.14    October 2025       October 2030

References
Status of Python branches: https://devguide.python.org/#status-of-python-branches
Annual release cycle for Python: https://www.python.org/dev/peps/pep-0602/

On Saturday, November 21, 2020 at 12:52:08 AM UTC-5 [hidden email] wrote:
Note that this is discussing support in Django 4.0 (which is the main development branch after stable/3.2.x is created).

4.0 will be released December 2021. Python 3.6 is EOL that very month

> 3.6 2021-12-23

The next version of Django (3.2) will support Python 3.6

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e1e965a3-9dfd-4c9a-bb36-eca8d970abe8n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Carlton Gibson-3
Hi Tim. 

Thanks for the breakdown, and context on the rationale. 

Do you think we can drop support for Python versions as they go EOL? 
i.e. for Django 2.2 we COULD HAVE stopped testing against Python 3.5 when it went EOL earlier this year. 
Given the backport policy, there's no reason to suspect it would break, but we'd not guarantee that.
(I do worry a bit about saying we support somebody else's EOL software...) 

Assuming that, there's a diagram in PEP 602 (on the Annual Release Cycle) that shows we'd essentially be on the hook for 5 Python versions forever.
https://www.python.org/dev/peps/pep-0602/#the-testing-matrix

If that's too many, how would something like "Django supports the latest 4 versions of Python" sound? 
This would mean dropping the oldest version ≈12 months before it reached end of life. 
(We'd have to think about mapping to our 8 month release cycle.)

Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/15cd90d9-559f-435d-a07c-724c9b4ac839n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Florian Apolloner
In reply to this post by Tim Allen
I think Redhat realized that they have old versions and this is not going to fly well during the lifetime of their system. This is why they introduced modules in v8 and strongly pushing podman. That said, it is a major hurdle for many companies if upstream drops support for $x (be that in python, php or whatever). I think this is also one of the reasons why containers are so popular. But do we really want to push users that much towards containers? Are there any big Django users our there that provide RPM packages and could give us some insights?

Cheers,
Florian
On Friday, November 20, 2020 at 11:52:51 PM UTC+1 Tim Allen wrote:
I often hear Ubuntu thrown around during these discussions, and it is my distro of choice for personal projects. But like many of us, I work at a RedHat / CentOS shop, and trying to maintain a current Python version is a much more difficult proposition. Unfortunately, IUS Community has stopped providing yum-installable versions of Python in an attempt to get EPEL to be more up to date, but that hasn't happened. To get a version of Python greater than 3.6 on RedHat / CentOS, AFAIK, you currently must build from source with altinstall.

I agree with Andrew's statement that we should consider each version. I can see dropping Python 3.5 support - it would allow us to use a feature like f-strings, which improves readability and speed throughout the codebase, and is ubiquitous in Python. But what does dropping Python 3.6 support really achieve? Do we need data classes?

I realize there is a need to move forward, especially for wonderful things like better async support. I just ask that we also consider those of us using Django in corporate or academic settings where the pace of upgrading Python is a bit more glacial.

On Thursday, November 19, 2020 at 11:51:29 AM UTC-5 Andrew Godwin wrote:
I agree we should not be quite so beholden to our existing Python version policy - that was mostly to get us out of the early 3.x era. Now things are more stable, I'd support a policy that is much more like "any stable version of Python currently out there and supported".

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1e1085e8-a175-4707-be04-cd3073ce7febn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Tim Graham-2
In reply to this post by Carlton Gibson-3
Dropping support for Python versions as they go EOL in existing Django releases would be disruptive. Distros "support" Python versions longer than the PSF does. If a Django version inadvertently breaks compatibility with an old version of Python because we stop testing with it, we'll get bug reports about it. It's happened before although I can't remember the exact circumstances offhand. It's not good to put users in the position of unpredictably being unable to update to a Django security release because their Python is old and a security update inadvertently broke compatibility. That would be a heavy stick whereas there's already been some hesitance here to the "carrot" argument of the current policy which restricts older Python users to a Django LTS.

I also thought about something like "support X versions of Python," and while I haven't studied the implications in detail, it doesn't strike me as significantly better or worse than the alternatives. I think we should wait a few years to see how Python's annual releases interplay with Linux distros before considering making Django's Python support policy more aggressive in dropping old Python versions.
On Tuesday, November 24, 2020 at 3:41:29 AM UTC-5 [hidden email] wrote:
Hi Tim. 

Thanks for the breakdown, and context on the rationale. 

Do you think we can drop support for Python versions as they go EOL? 
i.e. for Django 2.2 we COULD HAVE stopped testing against Python 3.5 when it went EOL earlier this year. 
Given the backport policy, there's no reason to suspect it would break, but we'd not guarantee that.
(I do worry a bit about saying we support somebody else's EOL software...) 

Assuming that, there's a diagram in PEP 602 (on the Annual Release Cycle) that shows we'd essentially be on the hook for 5 Python versions forever.

If that's too many, how would something like "Django supports the latest 4 versions of Python" sound? 
This would mean dropping the oldest version ≈12 months before it reached end of life. 
(We'd have to think about mapping to our 8 month release cycle.)

Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/583eb421-345f-4e19-b713-aeac9a1bca55n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting Python support for after Django 3.2 LTS

Carlton Gibson-3
Thanks again Tim. I really appreciate your insight. 

On Tue, 24 Nov 2020 at 19:07, Tim Graham <[hidden email]> wrote:
That would be a heavy stick whereas there's already been some hesitance here to the "carrot" argument of the current policy which restricts older Python users to a Django LTS.
[...]
I think we should wait a few years to see how Python's annual releases interplay with Linux distros before considering making Django's Python support policy more aggressive in dropping old Python versions.

Yes, so dropping 3.6 and 3.7 (as per the current policy) for 4.0 is the “carrot”, and almost as fast as we can go. 🤔

It’s a little surprising (is all) — Mariusz and I had been discussing dropping 3.6 without 3.7 ever coming into mind.

There’s time here for other comments. 

Kind regards, 
 Carlton 

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpySkRJ3njY6zv-_0v7CLUC--218kwO-UYMaNcKMgGm3bAg%40mail.gmail.com.