Adopting a set of "supported" python versions

[m3vaz]

Right now the project doesn't have any set of explicitly supported python versions. NEP 29 provides an example of how this can be done:

All minor versions of Python released 42 months prior to the project, and at minimum the two latest minor versions.

Minimum Python ... version support should be adjusted upward on [a] major and minor release, but never on a patch release.

This language also allows forecasting of python versions and forecasting (of some degree) of the resources required to maintain the project due to PEP 602 which normalizes the release schedule of python versions.

There are at least two areas this practically impacts:

• Support for version specific issues. Having a specified set of support versions allows some version specific issues to be termed in or out of scope, and be prioritized appropriately.
• Binary distributions are currently made available on pypi and the nvidia channel of conda-forge, this bounds for which versions of python the binaries are targeted.

[m3vaz]

@vzhurba01 Thoughts?

[vzhurba01]

Thanks @m3vaz for bringing this up! This is essentially what many libraries follow, and we should do the same.

Since CUDA Python is close to the base of the stack, it should take care to:

1. Support new versions sooner
2. Drop versions a little later

(1) Same as NEP 29
(2.i.) Raise issue when dropping a version is being considered
(2.ii.) Perhaps drop support on 2nd release after NEP 29 drop schedule

So as a policy it would be: "we promise we will drop support for old versions no faster than NEP 29."

Leaving issue open until this policy is stated and Python 3.11 is added.

[vzhurba01]

Added Supported Python Versions specifying supported versions and the policy adopted as per above.

Opened a separate issue #41 to track Python 3.11 support. Closing.