Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

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/

[Jure Erznožnik]

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

> --
> 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 django-develop...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%40googlegroups.com.

[Paolo Melchiorre]

Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson <carlton...@gmail.com> 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

[Andrew Godwin]

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

[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.

[Carlton Gibson]

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

[Ahmmed Sabbir]

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.

[Tim Graham]

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/

[Carlton Gibson]

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

[Florian Apolloner]

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

[Tim Graham]

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.

[Carlton Gibson]

Thanks again Tim. I really appreciate your insight. 

On Tue, 24 Nov 2020 at 19:07, Tim Graham <timog...@gmail.com> 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 

[Claude Paroz]

Like others in this thread, I think that dropping Python 3.7 for Django 4.0 is too aggressive, even if it complies with the written policy.

So I would plead for an exception and ask to keep Python 3.7 for Django 4.0 at least. Is there support for this idea here?

Claude

[Carlton Gibson]

HI Claude. 

Thanks for following up  on this.

I’d **like** to follow a slower policy — I’d more or less like us to be able to say that if you’re on a non-EOL Python we support you. 

BUT I’m struggling to think how we manage it, given Tim’s points. 

If we were to make a bit more explicit something like “If you’re not on the LTS, then you need to think about updating Python and Django in line with the release cadence” then MAYBE we could drop 3.7 (say — I didn’t look at the dates again) after 4.0, obliging people to move up then. 

In general what do we think about that kind of thought? It seems to be Tim’s point about being stranded without security cover, yes? 

My thought there is that we could quite reasonably say, “You should be on the LTS, that’s why we go to all the work of maintaining it” for such a case, but I don’t know if that’s defensible. 

The other point was the size of the CI matrix (which the LTS makes larger still...)

Not sure. 

C.

--

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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%40googlegroups.com.

[Claude Paroz]

When I see that Python 3.7 will be supported the whole time of the 4.0 support period, it's enough for me. For the rest, let the people choose and see by themselves through the support graphs what their interest is. I think we should stop patronizing developers.

Claude

[Carlton Gibson]

OK, so... 

Updating Tim's table to have "A version of Django will support current Python versions who's EOL date is not before it's own EOL date" would give us: 

Django      Released              End of life              Support Python Versions

4.0             December 2021  April 2023               3.7, 3.8, 3.9, 3.10

4.1             August 2022        December 2023    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)

5.0            December 2023   April 2025              3.9, 3.10, 3.11, 3.12

5.1            August 2024         December 2025   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)

Python  Released           End of life

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

This looks like it would mean in general supporting 4 versions of Python and 5 for the LTS. 

The .1 and LTS would drop a version against the .0

I'd go for this, at least through the next cycle or so. 

(Django 6.0 might look as if it's on the hook for the full 5 versions 🤔 but I think we could revisit before then.)

My concern is the paragraph in Tim's reply above that begins "Part of the rationale for dropping Python versions after an LTS is was to avoid getting "stranded" on a non-LTS version of Django." — I'm not sure we can do anything there apart from maybe say that people have to update their Python. (I'm not sure we have the capacity or duty to do more if folks are lingering here?)

How do we decide? Mariusz has opened the PR to drop both 3.6 and 3.7 support. 

https://github.com/django/django/pull/13915

We can merge the 3.6 stuff, but it would be nice to settle this. 

(I don't know)

Kind Regards,

Carlton

[Tim Graham]

Hi Carlton, This chart doesn't look quite right for the policy you wrote. For example, I wouldn't expect Django 4.2 LTS (supported until April 2026) to support Python 3.8 (only supported until October 2024). It seems like this policy makes it more likely that the last Django version to support a Python would be a non-LTS rather than an LTS. Maybe that's fine.

It might also be helpful to clarify the backport policy for Python version support. Something like, "the latest stable version of Python will be supported in the latest stable version of Django (and the latest Django LTS)". For example, unlike your chart, I had Python 3.13 backported to 4.2 and 5.0.

[Claude Paroz]

Le mercredi 20 janvier 2021 à 16:19:09 UTC+1, timog...@gmail.com a écrit :

... It seems like this policy makes it more likely that the last Django version to support a Python would be a non-LTS rather than an LTS. Maybe that's fine.

In my opinion, that's fine. As Python supported versions for Django releases are documented, people can decide by themselves their choice and assume it. It's not like it has come by surprise.

Claude

[Carlton Gibson]

On Wed, 20 Jan 2021 at 16:19, Tim Graham <timog...@gmail.com> wrote:

This chart doesn't look quite right for the policy you wrote. For example, I wouldn't expect Django 4.2 LTS (supported until April 2026) to support Python 3.8 (only supported until October 2024).

Yep, my error. Please read as intended rather than as written. I’ll trust your superpowers for that. 😃

It might also be helpful to clarify the backport policy for Python version support. Something like, "the latest stable version of Python will be supported in the latest stable version of Django (and the latest Django LTS)". For example, unlike your chart, I had Python 3.13 backported to 4.2 and 5.0.

Yes, this is something to clarify while we’re here.

Strong demand for the latest version is expected (given previous experience). 

It’s this point that we get into the possibly 6 versions though, which is a lot. 

Not quite sure what to say about that (recalling your earlier points). 

C.

[Mariusz Felisiak]

Hi y'all,

    I think we should keep the current policy. There is never a good time to drop support for anything and extending support especially for Python 3.7 will end with more exceptions in the future. Current policy is really patronizing and with the new Python release schedule we can reach 6 supported versions of Python for every LTS. I would make it even more aggressive :) It's not only about the maintenance burden but also about new features and syntax, we have tickets waiting 2-3 years until Python X becomes the minimal Python supported by Django. My 2 cents 🤷

Best,
Mariusz

[Tim Graham]

Looking at this again, I'm not sure it would be six versions. Carlton's suggested policy has the effect of dropping a lot of Python versions right before the LTS since it's supported for 3 years. For example, in Django 5.2 LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported since their support expires in Oct 2026 & 7, before Django 3.2's expiration in April 2028)? The current policy means we have Django LTS's supporting some Python's well after they expire. I never liked that aspect of it. Anyway, the decision won't affect my life.

[Carlton Gibson]

OK... urgh. I don't think there's a perfect answer here. 

As you say Tim, assuming the "support unless EOL before the Django version's EOL"  we end up dropping the Python version before the LTS, which is going to be just as "premature" as we have now, but for the x.0. 

If I've not counted wrong (again) the 4.2 LTS, for example, due April 2023, would drop Python 3.8 and 3.9, which have until Oct 2024 and 2025 to run. 

So we'd be trading extra life here for probably more complaints there. 

I've played around with various variations of the cut-off date without any real ground being made. 

Thus, we probably need to stick as we are, in the main. 

A last option would be to say that the x.0 will support one extra older version after the LTS, in cases like this where the otherwise dropped version is supported for the whole lifetime of the x.0 release. 

That I think would look like this, assuming we backport support for new versions within the mainstream support period: 

4.0    : 3.7, 3.8, 3.9, 3.10

4.1    : 3.8, 3.9, 3.10, 3.11

4.2 LTS : 3.8, 3.9, 3.10, 3.11, 3.12

4.2 is in danger of taking 3.13 as well, but that's released after 4.2 leave mainstream support.

It's akin for what we did for Django 2.2 and Python 3.9

That's independent of whether we keep support for 3.7 a bit longer. 

Having looked it through now, I think, fully, that's my final thought. 

I'd need to think about the __exact wording, but I hope the idea is clear.

I take Claude's point about contributing but, for me, the desire to support slightly more versions if we can is for beginners, picking up a couple of year old laptop, with SOME version of Python on it, and being able to get going, with hopefully the latest version. I appreciate they can install an older version, but it's hard enough to get started without hitting subtle version changes. I'd like to support that use-case as best we can. 

The current policy begins, "Typically...". I'd suggest supporting Python 3.7 for Django 4.0 is merely leveraging that. 🙂

We should decide. I'd be +1 to maintain the current policy but keep 3.7 support for Django 4.0, dropping it at Django 4.1. 

Thanks all, and especially you Tim for taking the time to explain and explore the options. 

C.

[Markus Holtermann]

I think I need to go through all proposed options a few more times to understand their differences and implications.

But what about a more pragmatic approach: Django supports the currently supported Python versions at any given time. Except for our LTS versions, which would never drop support. That means, a Django 2.2 might need to get fix in 2.2.x to support e.g. Python 3.11. But if Python support for 3.8 is dropped, why not drop it from Django' non-LTS versions. Where "drop" is meant as a , we won't add fixes to support an old Python version, and we won't add new features from a new Python version that's around. But if a new Python version requires a fix, let's back port it.

Cheers,

Markus

> --
> 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 django-develop...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/ef691a05-1a1a-434f-bd0c-56b6f5d8a027n%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/ef691a05-1a1a-434f-bd0c-56b6f5d8a027n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Florian Apolloner]

> Except for our LTS versions, which would never drop support.

Mhm, I'd support such an approach only if we have a clear idea for security issues. Assume LTS supports Python 3.x to 3.z. Python 3.x goes EOL and has a security issue that affects Django LTS -- what do we do? On one hand there are distributions that actively support and backport to EOL versions, others are rolling release version and always on the latest which we simply cannot support in LTS. As much as I hate it, containers are more and more becoming the answer (FWIW I think podman is doing a great job in that regard with systemd integration etc).

No matter which way we will choose, there will be dragons.

Cheers,

Florian

[Carlton Gibson]

Hi all. 

Thank you for all the discussion. tl;dr "It's Hard™" :)

But we need to decide, so that we can merge Mariusz' PR and move on. 

I think we don't have a perfect new policy (yet). So let's bump that. There's no urgency to decide.

Possibly we could support Python 3.7 just for Django 4.0, as an exception, leveraging the "typically" in the existing policy, and clearly stating what we were doing. 

Can I ask for (limited) thoughts just on that smaller proposal? 

As I've said, I'd be sympathetic to this, but what is the reason why not?

If there is no consensus for us to extend support for Python 3.7 to Django 4.0 in this way, then we will proceed under the existing policy, and drop both Python 3.6 and Python 3.7 for Django 4.0 (i.e. on the main development branch now). 

This may be fine but, to recall, this discussion came up because Python 3.7 is (Python) supported for the entire lifetime of Django 4.0. 

Thanks again. 

Carlton

[Ryan Hiebert]

On Feb 2, 2021, at 03:42, Carlton Gibson <carlton...@gmail.com> wrote:

Possibly we could support Python 3.7 just for Django 4.0, as an exception, leveraging the "typically" in the existing policy, and clearly stating what we were doing. 

Can I ask for (limited) thoughts just on that smaller proposal? 

As I've said, I'd be sympathetic to this, but what is the reason why not?

I may have missed it being stated in this conversation, so I want to make sure the reason for the current policy is understood. The reason why not to make this exception is to avoid releasing breaking changes at a minor version. To follow SemVer. We get to decide whether that’s enough reason.

[Carlton Gibson]

Hey Ryan, 

That is a good question. Do we take the X in an X.Y series in the SemVer way. 

I’ve always thought not — the difference between 2.2 and 3.0 or 3.2 and 4.0 isn’t really a Major version change™ — we just roll on the same regardless of the number (with slight wiggles for the deprecation policy). 

Roughly counting here it seems like Me, Claude and Tim A would be +1, Tim G and Mariusz I’m taking as -1, and a few that I wouldn’t put anywhere. 

Similarly to last time round, that doesn’t really seem like a consensus to do something different. So I think continuing with the current policy for the next cycle seems favourite. 

I’ll leave this here for another day or so in case there are further comments.

Otherwise we’ll proceed. 

Thanks all. I know lots of folks are already on 3.8 and beyond, but I think it’s important that we at least think about it. 

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 django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/39C52096-7251-4597-B879-BCC7146AE683%40ryanhiebert.com.

[Ryan Hiebert]

On Feb 2, 2021, at 11:29 AM, Carlton Gibson <carlton...@gmail.com> wrote:

That is a good question. Do we take the X in an X.Y series in the SemVer way. 

I’ve always thought not 

When we switched the version scheme ahead of 2.0, we wanted it to roughly match SemVer. We’ve strategically weakened it in some places, and recognize that breaking changes may be practical in any version.

One place that SemVer was strategically weakened was by allowing features that were only deprecated at the LTS release to persist until the .1 release, so that there would always be at least 2 versions before a feature is removed after deprecation.