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 On Wed, Jan 27, 2021, at 4:22 PM, Carlton Gibson wrote: > 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. > > > > On Tuesday, 26 January 2021 at 22:00:31 UTC+1 timog...@gmail.com wrote: > > 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. > > On Tuesday, January 26, 2021 at 5:32:50 AM UTC-5 Mariusz Felisiak wrote: > >> 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 > > -- > 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-developers+unsubscr...@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>. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/83914cca-bd5f-4e16-992f-4d3b5adf53dd%40beta.fastmail.com.
