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 On Wednesday, 27 January 2021 at 22:12:42 UTC+1 f.apo...@gmail.com wrote: > > 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 > On Wednesday, January 27, 2021 at 8:50:49 PM UTC+1 > in...@markusholtermann.eu wrote: > >> 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-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>. >> >> >> > -- 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/cfa73c59-016b-4d04-98dc-be0144a6b332n%40googlegroups.com.
