issue_comments

reopening so I can keep track of the second task: creating and automatically updating the support table

@keewis - you are probably the best person for this task. Can you take on updating our min_deps_check.py script?

In the meeting today we decided to both change the min-versions policy for python to 30 months, and to add a release table (something like the one in NEP29, but automatically created with each newly released version – possibly through a polling action that runs once a week or something so we don't increase the docs build time any more). The reason for the latter is that the policy, while a good policy, is not easy to understand, and its full meaning can only be inferred by reading the min_versions_policy script.

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

This seems like a good action item to come from this. And seems to align with the thrust of #7777.

@keewis - thanks for the clarifications on the the version policy related to Python 3.8. Very helpful.

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

This is an interesting proposal. Worth considering.

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.