Description
Summary
This issue exists to consolidate discussion on support schedules for dependencies, in particular Python and Numpy, as these form the basis of the scientific Python ecosystem and are generally the most painful to upgrade. It additionally provides the canonical plan of release dates and version support matrix.
As release dates and support schedules get decided and modified, this schedule should be updated.
Schedule
Milestone/Tag | Date | Python | numpy | Notes |
---|---|---|---|---|
1.2.2 | 2019.09.07 | 2.7, 3.4+ | 1.9+ | Off-schedule release to support downstream projeects |
1.2.3 | 2019.09.23 | 2.7, 3.4+ | 1.9+ | Final Python 3.4 release |
1.3.0 | 2019.11.11 | 2.7, 3.5+ | 1.12+ | Final Python 2.7 series, begin 1.3.x bug-fix only branch; Drop 2.7 on master ; import workflows from niflows |
1.3.1 | 2019.11.12 | 2.7, 3.5+ | 1.12+ | 1.3.0 + backported bug fixes only |
1.4.0 | 2019.12.16 | 3.5+ | 1.12+ | All new features post-1.3.0 |
1.3.2 | 2020.01.06 | 2.7, 3.5+ | 1.12+ | 1.3.1 + backported bug fixes only; further 1.3.x releases only as needed |
1.4.1 | 2020.01.27 | 3.5+ | 1.12+ | |
1.5.0 | 2020.02.24 | 3.5+ | 1.13+ | Move nipype1 examples to niflows |
... | ||||
2.0.0 | TBD | 3.7+ | TBD | pydra-based |
Support windows
Numpy has published NEP 29, a recommended deprecation policy for scientific software. While Nipype does not make heavy use of Numpy, we do interact with a lot of software that does, and so it seems wise to pay attention to this plan.
In nibabel (nipy/nibabel#803) it appears we're likely to follow a plan of NEP + 1 year in our schedule for dropping support for Python and Numpy, which is the approximate difference between our ad hoc support plan and Numpy's (relatively) aggressive plan. I've followed that schedule in the numpy releases above.