Open travishathaway opened 2 years ago
Personally I would suggest staying closer to NEP 29 than to the Python End of Life dates. This allows keeping a leaner and meaner codebase, profiting earlier from new features and performance improvements while still providing a reasonably long migration time of 42 months. Most scientific libraries already follow this schedule.
As for new versions, I would suggest starting up testing, CI and CD workflows right when a new version reaches beta. This way there will be a fair chance that the new minor Python version could be supported relatively soon, instead of the current situation where the latest conda release is still Python 3.9 while Python 3.10 is out for over 7 months.
It's worth stating (though maybe this is obvious) that the version support here is for Conda itself (and related tooling). While these tools are consumed by users of NumPy, etc., they are not dependent on NumPy themselves. They are also consumed by users outside of the NumPy (or even Python) space. So establishing support for Python-based tooling to use Python's EOL scheme is reasonable. It's also worth noting that Python itself has sped up its own release cycle; so, it is more nimble than it was in the past.
Would it be possible to get some movement this? Python 3.11 isn't supported by conda yet, and Python 3.12 beta is coming up. I would be nice if 3.12 support won't take as long as 3.11 is currently taking.
This PR proposes an official policy and schedule that conda organization can follow regarding its projects and their support for various versions of CPython.
Note: this is still a work in progress and community input and help is very much welcomed