> 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
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
> 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
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
> 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
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.
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
