RFC: Adhere to NEP29

[effigies]

We are generally not writing libraries intended for broad downstream use, with the exceptions of migas and nireports.

In nipreps/niworkflows#593 we discussed going by NEP29 (dropping support for Python versions after 42 months and numpy versions after 24 months) but it was never properly agreed upon.

I propose following NEP29 and adopting the following schedule:

Date	Python	NumPy
Apr 14, 2023	3.9+	1.21+
Jun 23, 2023	3.9+	1.22+
Jan 01, 2024	3.9+	1.23+
Apr 05, 2024	3.10+	1.23+
Jun 22, 2024	3.10+	1.24+
Dec 18, 2024	3.10+	1.25+
Apr 04, 2025	3.11+	1.25+
Jun 17, 2025	3.11+	1.26+
Apr 24, 2026	3.12+	1.26+

I would be okay adopting a more aggressive schedule for the workflows themselves. We are currently building fMRIPrep docker images with Python 3.10 and NumPy 1.24, a bit over a year ahead of NEP29.

[oesteban]

I agree with every word, and I believe it would make everything easier to maintain to adopt an aggressive schedule for workflows. Thanks for bringing this up :)

[effigies]

There is a new NEP29: SPEC0

This covers numpy, scipy, matplotlib, pandas, scikit-image, networkx and scikit-learn from our dependency tree. I believe it's identical to NEP29 for numpy, but is 6 months more aggressive for Python.

IMO we should adopt SPEC0 for our scipy stack, but can be a bit more flexible with dropping Python support. My inclination is to use the formula: max(SPEC0, min(end-of-life, pain)). If keeping CI up either takes too much effort or too many clock cycles, we can drop, but if it costs us little, might as well keep going.