Python version floor: drop 3.9 (and maybe 3.10) after the next release?

[lawrennd]

Context

GPy currently declares python = ">=3.9,<4" (pyproject.toml, CIP-0003), while CI and wheel builds only exercise 3.11–3.14. So 3.9/3.10 are in the metadata floor but are not in the test or packaging matrix.

This discussion is about when and how far to raise that floor — not about doing it immediately.

Timing constraint (proposed)

Do not raise the floor in the next release. Ship the current maintenance work (Poetry/NumPy 2, CIP-0005 lint, Codecov, bugfixes) so 3.9 (and 3.10) users still benefit from those changes on a release that still declares >=3.9.

Propose any floor change for a following release (e.g. next minor after that), announced in the release notes of the upcoming one.

Ecosystem calendars

Policy	Python 3.9	Python 3.10	Notes
CPython EOL	2025-10-31 (PEP 596)	~2026-10 (PEP 619)	No further security fixes from upstream
SPEC 0 (3 years after feature release)	Drop recommended since ~2023-10	Drop recommended since ~2024-10	NumPy/SciPy/etc. endorse SPEC 0; schedule already past 3.9/3.10
GPy today	Declared supported	Declared supported	Not in GHA matrix; no cp39/cp310 wheels in current release workflow

So: declaring >=3.9 is already ahead of what we test and ship as wheels, and behind SPEC 0 / CPython EOL for 3.9.

Related history to fold in

Precedent discussions / policy:

• #1028 — Let's drop support for all Python < 3.7? (closed; agreed maintenance burden; note to move slowly / announce ahead of a later release — same pattern as here)
• #914 — Drop Python 3.5 support? (closed; asked for a record of “last GPy version supporting Python X.Y”)
• #1038 — Limit maximum python version (closed; about capping the upper bound when new Pythons break us — related policy hygiene)
• CIP-0003 — packaging floor >=3.9; CI documented as 3.11–3.14
• CIP-0005 — Ruff UP038 (X | Y unions / isinstance PEP 604) deferred until floor ≥ 3.10 (or higher)

Dependency / install pressure (why modern floors matter):

• #1112 / #1119 — NumPy 2 / modern SciPy stacks

Stale install issues on already-unsupported Pythons (candidates to close with a pointer once a new floor is decided):

• #713 — Windows / Python 3.7.1
• #818 — Cython / Python 3.6

Options

1. Keep >=3.9 for now (status quo metadata; next release still installs on 3.9)
2. After next release → >=3.10 (drop 3.9 only; unlocks UP038-style cleanups that need 3.10+)
3. After next release → >=3.11 (match CI/wheels; drop 3.9 and 3.10 together)
4. Hybrid: announce in next release notes (“last release supporting 3.9[/3.10]”); raise floor on the release after that; optionally add a short “last supporting version” note in the wiki/README (per Drop Python 3.5 support? #914)

Pros of raising the floor (3.9 and/or 3.10)

• Honesty: metadata matches what CI and wheels already cover (especially if moving to >=3.11).
• SPEC 0 / EOL alignment: 3.9 is past CPython EOL; both 3.9 and 3.10 are past SPEC 0’s 3-year window.
• Less matrix fiction: fewer “supported but untested” combinations; clearer triage for install bugs.
• Lint / language cleanup: CIP-0005 can enable UP038 once floor ≥ 3.10; further modern typing/syntax becomes easier at 3.11+.
• Dependency reality: NumPy/SciPy/matplotlib already pressure users toward newer Pythons; fighting that in GPy costs time (GPy==1.13.2 cannot be installed with newer SciPy/NumPy stacks due to strict upper bounds #1119-style resolver pain).
• Precedent: project already raised floors before (Drop Python 3.5 support? #914, Let's drop support for all Python < 3.7? #1028) with maintainer agreement that old minors are a burden.

Cons / risks

• Users stuck on 3.9/3.10 (institutional images, teaching stacks, long-lived envs) lose new GPy releases — mitigated if the upcoming release still supports them and we document “use GPy==X.Y.Z on Python 3.9”.
• 3.10 is still within CPython security support until ~Oct 2026 — dropping it sooner than 3.9 is a sharper cut; SPEC 0 already allows it, but user impact may be higher than dropping 3.9 alone.
• Perception: dropping support can look aggressive if not announced one release ahead (ekalosak’s point on Let's drop support for all Python < 3.7? #1028 still applies).
• paramz / downstream: any shared floor should stay consistent with paramz and documented install paths.
• Not a substitute for testing: if we keep declaring 3.9/3.10, we should either add them to CI (cost) or admit they are best-effort — raising the floor is one way to resolve that tension; expanding CI is the other.

Recommendation to debate

1. Ship the next release still on >=3.9 so current devel fixes reach 3.9 users.
2. In that release’s notes, announce intent to require >=3.11 (or at least >=3.10) on the following minor/major.
3. Prefer >=3.11 over >=3.10 unless someone has a concrete 3.10-only user base: it matches CI/wheels today and avoids a two-step migration.
4. When the floor moves: update pyproject.toml, README, CIP-0003, classifiers; enable CIP-0005 UP038 if floor ≥ 3.10; close obsolete ancient-Python install issues with a pointer here.

Questions

• Any known blockers for dropping 3.10 (not just 3.9) in teaching/deploy environments?
• Prefer announce-then-drop over two releases, or a longer deprecation window?
• Should we add a one-line “Last GPy version supporting Python 3.9 / 3.10” table (as suggested in Drop Python 3.5 support? #914) when we cut?

Comments welcome — especially from anyone still on 3.9/3.10 in production or teaching.

[lawrennd]

Pinging heavy / long-time contributors for awareness (no action required unless you have a stake in 3.9/3.10):

@mzwiessele @jameshensman @alansaul @MartinBubel @ekalosak @zhenwendai @nfusi @mikecroucher @bobturneruk @letterdaniel @AlexGrig @lionfish0 @ric70x7

Especially relevant if you still see GPy used on Python 3.9 or 3.10 in teaching or production — please comment on the options above. Reminder: proposal is to keep >=3.9 for the next release, then raise the floor afterwards.

[lawrennd]

We are doing the sequence this discussion recommended, with Dependabot/Pillow 13 pulling the 3.11 floor immediately after this cut rather than one extra minor later.

1.15.0 (#1235) still declares >=3.9. Wheels remain 3.11–3.14, as in 1.14.x. Release notes call this the last declared 3.9/3.10 release.

Lockfile hygiene without the floor: #1233 takes Pillow 13 on 3.11+, nbconvert 7.17.2, and certifi 2026.10.23. Unpatched 3.9-only pins stay until the floor moves.

After 1.15.0 is on PyPI: draft #1234 raises the floor to >=3.11 so the remaining Dependabot alerts can close. Pillow 13 has no wheel for 3.9, which is why we would not lift in 1.15 itself.

[lawrennd]

Update 2026-10-24. GPy 1.15.0 is the GitHub Release this thread called for.

• Release: https://github.com/SheffieldML/GPy/releases/tag/v1.15.0
• Metadata still declares python >=3.9 (3.9 and 3.10 users can take this cut).
• Release notes announce that the next minor requires Python >=3.11.
• Last GPy version declaring 3.9 / 3.10: 1.15.0. Binary wheels remain 3.11–3.14, as in 1.14.x.

PyPI lists 1.15.0. Use pip install gpy==1.15.0.

Floor follow-up (draft, do not merge until 1.15.0 is on PyPI): #1242

This discussion stays open until #1242 lands. Then we can add the one-line “last supporting version” note (#914) and close.