Personally I would be in favor of updating NEP 29 to a support timespan in which at most 3 (minor) Python versions are supported. The development of Python is still at a high pace and NumPy is a high performance library which thrives when be able to adopt the latest Python features and having clean codebase without having "if sys.version_info[:2] < (3, n):" guards everywhere. Especially with the developments of the faster Faster CPython project and the continued improvements in type hinting support, I think shortening the support timespan a bit is reasonable, beneficial and proportional. More important, NEP 29 is adopted by many other projects, providing a signal to the ecosystem that's okay to focus on the latest Python versions. The overlap between users using a Python version more than 2.5 years old and wanting the latest features and performance is probably pretty small. Older NumPy and other project's releases will won't disappear and be usable when the Python requirements are lifted. In my opinion a 30 month support window would provide a nice balance. Each Python version is supported for over 2 minor releases, with updates on the maintenance branches extending that with another few months. You can comfortably stay a full minor Python version behind year-round and still use the latest NumPy. For even older Python versions the old NumPy releases will stay available, and it allow NumPy to move on to new Python features a full year earlier then with a 42 month support window. Which not only improves feature and performance adaptation, but also lowers maintenance, testing, backporting and CI effort. Ewout ter Hoeven (EwoutH)