Closed m3vaz closed 1 year ago
@vzhurba01 Thoughts?
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) 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.
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.
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:
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:
nvidia
channel of conda-forge, this bounds for which versions of python the binaries are targeted.