Update supported Python versions: 3.10–3.14 (standard) + 3.8/3.9 (legacy)

[ganow]

Summary

Shift the supported Python window for the next release:

Tier	Current (v0.26)	Proposed
Standard support (main / dev)	3.8 – 3.11	3.10 – 3.14
Legacy support (maintenance/legacy)	3.6 – 3.7	3.8 – 3.9
Unsupported	< 3.6	< 3.8

Motivation

Follow the upstream Python support schedule.

Python 3.8 and 3.9 are currently standard-support versions in v0.26. This issue proposes moving them to the legacy branch rather than dropping them outright, since they were recently supported. If the maintenance cost turns out to be non-trivial, dropping them entirely is also acceptable.

[ganow]

Investigation notes

After investigating the feasibility of this issue, this cannot be fully implemented until #121 is resolved first.

Why 3.12+ is currently blocked

The mri extras pin numpy<1.24 and nibabel==3.2. These pins exist because bdpy/mri/ uses APIs that were removed in later versions of those libraries (#121 tracks the fix). The key blockers are:

• numpy<1.24 has no wheels for Python 3.12+. The highest version in this range, 1.23.5, ships wheels only for cp38-cp311 (PyPI). Python 3.12 support first appeared in numpy 1.26.0, which also migrated to a new build system after Python 3.12 dropped distutils (numpy 1.26.0 release notes).
• nibabel==3.2 is an exact pin. The 3.2.0 release was tested only up to Python 3.8; Python 3.12 was first explicitly tested in nibabel 5.2.0 (nibabel changelog).

Since bdpy[mri] is a first-class supported extra, 3.12-3.14 support is impossible without first completing #121.

Proposed strategy (for when #121 is done)

Rather than the two-branch model described in this issue, a single-branch approach is cleaner given the current release workflow:

• requires-python = ">=3.8, <3.15" ensures Python 3.8/3.9 users receive the next release when running pip install bdpy. pip selects the latest release whose Requires-Python matches the running interpreter; if 3.8/3.9 were excluded from the next release, those users would silently receive the previous release instead (Python Packaging User Guide).
• Standard support: 3.10-3.14, tested in blocking CI jobs (failures block merges)
• Legacy support: 3.8 and 3.9, tested in non-blocking CI jobs (failures are visible but do not block merges or releases; users can be directed to 3.10+ if issues arise)

The distinction between blocking and non-blocking is implemented via continue-on-error in GitHub Actions:

jobs:
  test:  # standard support: blocks merges on failure
    strategy:
      matrix:
        python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"]
    steps:
      ...

  test-legacy:  # legacy support: failures are visible but do not block merges
    continue-on-error: true
    strategy:
      matrix:
        python-version: ["3.8", "3.9"]
    steps:
      ...

The two-branch approach from the issue description would require maintaining two independent release lines with separate version numbering and manual publish steps, which is too much overhead for the goal of softly demoting 3.8/3.9.

Recommended order

1. Complete Loosen pinned dependency versions (numpy, nibabel) and support numpy 2.x #121 (update bdpy/mri/ to support current numpy and nibabel, relax the pins)
2. Then implement this issue: bump the Python window to 3.10-3.14 standard + 3.8/3.9 legacy tier

[KenyaOtsuka]

Python version bump: 3.13 is reachable, 3.14 is currently blocked for bdpy[mri]

I looked into raising the standard support window. 3.10–3.13 work fine, but 3.14 is currently blocked by nipy.

What's blocking 3.14

bdpy[mri] depends on nipy. The latest release is 0.6.1, and it ships no cp314 wheel or sdist (only cp38–cp313 wheels). There's no newer version to bump to, and it's unclear whether/when 3.14 will be supported.

How nipy is actually used

There seem to be two functional uses of nipy in bdpy[mri]:

1. Image loading — nipy.load_image() in bdpy/mri/load_mri.py, load_epi.py, and fmriprep.py.

   These paths only use image data, shape, and the affine mapping (coordmap.affine). This should be straightforward to replace with nibabel, which is already an MRI dependency and does not depend on nipy. The main mapping is roughly coordmap.affine → affine.

2. GLM paradigm objects — BlockParadigm / EventRelatedParadigm from nipy.modalities.fmri.experimental_paradigm in bdpy/mri/glm.py::make_paradigm.

   This is different from the image-loading case. make_paradigm() currently returns these nipy-specific objects directly, so removing nipy here would require an API-level decision: either reimplement the returned paradigm representation in bdpy, or migrate the GLM design handling to another stack such as nilearn.

Suggested paths

I think there are two realistic options:

1. Cap the next standard support window at 3.13.

   Ship standard support as 3.10–3.13 for now and keep nipy as-is. This is the smallest change, and 3.14 can be revisited later.

2. Remove the nipy dependency before claiming 3.14 support.

   Replace the nipy.load_image() paths with nibabel, and also reimplement or migrate make_paradigm so that bdpy[mri] no longer depends on nipy. After that, bdpy[mri] would no longer be blocked by nipy for Python 3.14.