Re: Revisiting Python support for after Django 3.2 LTS

[Ryan Hiebert]

> On Feb 2, 2021, at 11:29 AM, Carlton Gibson  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.

-- 
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/6333A98C-EC9F-474D-9D6E-5A659B9EEE30%40ryanhiebert.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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


On Tue, 2 Feb 2021 at 13:34, Ryan Hiebert  wrote:

>
>
> On Feb 2, 2021, at 03:42, Carlton Gibson  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.
>
> --
> 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/39C52096-7251-4597-B879-BCC7146AE683%40ryanhiebert.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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyROQxN919btfQR9qJAvVRA1yvev3RqULmxjLHrxkW%2BpPA%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Ryan Hiebert]

> On Feb 2, 2021, at 03:42, Carlton Gibson  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.

-- 
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/39C52096-7251-4597-B879-BCC7146AE683%40ryanhiebert.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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



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 

Re: Revisiting Python support for after Django 3.2 LTS

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

Re: Revisiting Python support for after Django 3.2 LTS

[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

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
>  

Re: Revisiting Python support for after Django 3.2 LTS

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



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.

Re: Revisiting Python support for after Django 3.2 LTS

[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.
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/4dd42d46-ffe7-432f-8572-5a261c4fd0fcn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

>

-- 
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/63118c58-e698-4662-9d49-a7a2875ae0b7n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

On Wed, 20 Jan 2021 at 16:19, Tim Graham  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.

-- 
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/CAJwKpyTFj9bm3SdPo5iu2g-AdYRZuGxodbz9L5XNV0CpA0Zeug%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

-- 
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/c05845d8-7e25-437f-9683-7474a80d75ffn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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.
On Wednesday, January 20, 2021 at 3:21:44 AM UTC-5 carlton...@gmail.com 
wrote:

> 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 2022December 20233.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.0December 2023   April 2025  3.9, 3.10, 3.11, 
> 3.12
> 5.1August 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 2018June 2023
> 3.8 October 2019   October 2024
> 3.9 October 2020October 2025
> 3.10October 2021   October 2026
> 3.11October 2022   October 2027
> 3.12October 2023   October 2028
> 3.13October 2024   October 2029
> 3.14October 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
>
>
> On Tuesday, 19 January 2021 at 20:36:21 UTC+1 Claude Paroz wrote:
>
>> 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
>>
>

-- 
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/a616ce7b-2096-4800-957b-1f92e1a525a4n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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 2022December 20233.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.0December 2023   April 2025  3.9, 3.10, 3.11, 3.12
5.1August 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 2018June 2023
3.8 October 2019   October 2024
3.9 October 2020October 2025
3.10October 2021   October 2026
3.11October 2022   October 2027
3.12October 2023   October 2028
3.13October 2024   October 2029
3.14October 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


On Tuesday, 19 January 2021 at 20:36:21 UTC+1 Claude Paroz wrote:

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

-- 
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/e9701425-b2ce-4c86-a6dd-0230fc011796n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

-- 
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/be97212d-00b8-4f9a-b8c7-1753580b8123n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

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

On Tue, 19 Jan 2021 at 18:20, Claude Paroz  wrote:

> 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
>
> --
> 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/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyQxWkRehcm%2BxdZXo%2Bi-XvWNhdLNk9W-_iRAa81SEvEoTA%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

-- 
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/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

Thanks again Tim. I really appreciate your insight.

On Tue, 24 Nov 2020 at 19:07, Tim Graham  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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpySkRJ3njY6zv-_0v7CLUC--218kwO-UYMaNcKMgGm3bAg%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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.
On Tuesday, November 24, 2020 at 3:41:29 AM UTC-5 carlton...@gmail.com 
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.
> 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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/583eb421-345f-4e19-b713-aeac9a1bca55n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1e1085e8-a175-4707-be04-cd3073ce7febn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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



-- 
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/15cd90d9-559f-435d-a07c-724c9b4ac839n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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  ReleasedEnd 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.10October 2021   October 2026
3.11October 2022   October 2027
3.12October 2023   October 2028
3.13October 2024   October 2029
3.14October 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 carlton...@gmail.com 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1e965a3-9dfd-4c9a-bb36-eca8d970abe8n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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.
On Thursday, November 19, 2020 at 2:50:45 PM UTC+6 pa...@melchiorre.org 
wrote:

> Hi all,
>
> On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  
> 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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c816360d-ee52-4b19-8d5f-f21a1277ab18n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

-- 
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/BD6D9F10-C307-4D0D-BDF6-FD1AAB81EEEF%40gmail.com.

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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/83fc7a73-aa7d-4390-805f-c50c496175f8n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

-- 
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/e1f40b9d-a017-4507-b855-2055713d960e%40www.fastmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Paolo Melchiorre]

Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx67iV6ENfs1WF7eGo9qMr%2BAMVpKOOJ9JZ_pwSWfsJeSgg%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[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

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  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 django-developers+unsubscr...@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.

-- 
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/CAJ%3D9zieOHxefv%2BpUF%2BT2xch-N%2BWusMeeaFv%3DGzFhHY_LNw%3DfAw%40mail.gmail.com.