Criteria for Python version end of life support

[davidlbaird]

I'd like to know if there is a clear criteria or guideline for ending support of a Python version. The recent removal of Python 3.7 support seems to be at the continuous test level, and stated version support. Support for Python 3.7 did not seem to affect any of the pyfakefs code itself, though I can see that future code changes would not require Python 3.7 support.

From another perspective, though, there are organizations and frameworks that take a while to drop reliance on older Python versions, even past their security patch support date. Should pyfakefs drop support of these organizations and frameworks because a new feature in a supported Python version becomes available? I have worked with organizations like that, though happily, the one I work in is very aggressive in updating Python versions as they become available.

Perhaps a policy for pyfakefs, in order to be friendlier to organizations and frameworks that rely on pyfakefs and cannot upgrade to newer Python versions at the same pace as they are dropped from security updates, is to drop pyfakefs support of unsupported Python versions when a newer Python feature is required for pyfakefs features.

[mrbean-bremen]

There isn't a guideline so far. I generally try to support outdated versions for some time (at least a few months), though in the case of Python 3.7 I may have been a bit too hasty. I have already considered to roll this back, and considering this issue I probably will.
The reason for this was some incompatibility with Python 3.7 (have to check what it actually was - may have been some missing support in the CI), but I agree that this was premature. I may have been influenced by other projects that remove support for a version as soon as it's EOL.

EDIT: I have reverted the removal of 3.7 support.

[mrbean-bremen]

Perhaps a policy for pyfakefs, in order to be friendlier to organizations and frameworks that rely on pyfakefs and cannot upgrade to newer Python versions at the same pace as they are dropped from security updates, is to drop pyfakefs support of unsupported Python versions when a newer Python feature is required for pyfakefs features.

The thing is that usually a new feature is not really required for pyfakefs, it just makes things easier. It also helps to make the code more readable if special cases for older versions are removed.

So I would say we go on a case per case policy here.

As a rule of thumb I propose to support EOL versions at least for 6 more months, and drop official support after the CI (e.g. GH Actions) drops support for that version. After that, we will not be able to test the version reliably anymore. Dropped support by the CI is also a good indication that the version is generally seen as unsupported in the wild.

We usually drop versions in minor releases (in the case of Python 2 in a major release), so that there is always the possibility to backport fixes to patch releases for the last pyfakefs version supporting that Python version. I would only do that on request though. So far, we have done this only for the 2.7 release, apart from that there were no requests to for prolongated support of any version.

[davidlbaird]

Yes, it makes sense to drop support when the CI tools do.