issue_comments: 1513673945

Is the policy working as designed

yes, it is: we guarantee support for at least 24 months, and only drop support once there's another version of python that was released more than 24 months ago. For example, python 3.8 was initially released on Oct 14, 2019 and python 3.9 was released on Oct 5, 2020. According to our policy we were able to drop python 3.8 for releases after Oct 5, 2022, since that's when python 3.9 was released 24 months ago.

This works very well for infrequent releases, since it guarantees that we don't accidentally require a very new version immediately after its release. However, these admittedly a bit complicated rules make interpreting the policy a bit more challenging than a simple "X months from this release" would for projects with frequent releases. Maybe we should add a (automatically created) support table for the core dependencies to the installation guide to make reasoning about the policy easier?

Python: 24 months from the last bugfix release (security releases are not considered).

That would make the support window less predictable, since the python devs might consider an additional bugfix release depending on the situation (there's a reason why the release peps say, emphasis mine: "X will receive bugfix updates approximately every 2 months for approximately 18 months"). Instead, maybe we should extend the support for python versions by about 6 months, to a total of 30 months? That would effectively align us with NEP-29, which is our upper limit anyways since that's what our dependencies follow (even if their releases don't usually happen at exactly that date).

And before anyone claims we're dropping support for a python version just because our policy tells us to: I'm excited about a number of changes to python, like the dict union and removeprefix / removesuffix in 3.9, the union types in 3.10, and the exception groups in 3.11, so really there is a compelling reason to upgrade as soon as the policy allows for each release.