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 maint

Re: First time contributor, requesting permission to work on #32340

[Surya Banerjee]

Hi Carlton,

Thanks for the directions. I have posted my question on the issue tracker.

Thanks,
Surya

On Tue, Feb 2, 2021 at 1:05 PM Carlton Gibson 
wrote:

> Hi Surya. Welcome
>
> Do comment on the ticket. Thibauld and Tom should be able to give you more
> specific advice.
> I'm not sure if Thibauld is already planning work, but there should be
> room to collaborate.
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 2 February 2021 at 02:25:10 UTC+1 Surya wrote:
>
>>
>> Hi team,
>>
>> I am a new contributor and working with Django as a Junior Developer.
>> After looking into issue tracker, I see #32340
>>  as a ticket that I would
>> love to work on if nobody else is working on it.
>>
>> In case I get to work on this, I had a couple of questions regarding what
>> needs to be done.
>>
>> 1. For the suggestion of having explicit instructions on the Django
>> documentation about the format of the form fields, as described in the
>> ticket, should I focus on mentioning the default formats for the following
>> fields -
>>
>>- Date and time fields – DateField, DatetimeField, TimeField,
>>SplitDateTimeField, DurationField
>>- More technical fields which have very specific formats: SlugField,
>>JSONField, UUIDField, RegexField, GenericIPAddressField
>>
>> 2. Should the changes in the documentation extend to issues such as
>> #32339  or #32338
>>  on why it should be
>> avoided?
>>
>> Please forgive me if I have not been able to understand the ticket
>> responsibility the way it is intended, and I would be very grateful if the
>> scope of the changes required could be pointed out to me by any senior
>> member of the community.
>>
>> Thanks,
>> Surya
>>
> --
> 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/4d49125a-61b0-43a7-9698-3ed7e78e6b06n%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/CABgd%3DVKt4vcpf0Tc4wngPe4p-YkcOcWdpj4iPAzyDh65fbFgug%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]

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