framework+rdm: establish Python support policy

[fenekku]

This is actually my summary of the discussions maintainers had. I've separated out my own comments / thoughts, so this should be understood.

Also in the below text "supported Python version" should be read as "officially supported by the Python foundation/community"

[slint]

Thanks for putting this down in writing, I really like how this is forming :)

Had a go at the "core" part of the RFC regarding supported versions across Invenio{,RDM,ILS}. I didn't have time/stamina to go through the transition periods, but I'll have a go again tomorrow.

[fenekku]

I pushed some edits.

Areas of discussion left (I can be swayed and it would be nice to hear from others too):

• Concretize the Officially Supported versus Compatible version concept: are they different enough in practice in other ways? what do maintainers think about them?
• Only 1 officially supported version at a time or could there be multiple? Effort to maintain?

I will recheck at the end of my day else when I come back from holidays (I am fine if a decision about this is done while I am away. Either way it shakes out, there is nothing I strongly disagree with).

[fenekku]

Ok I did a big rewordind/re-organizing pass through so that the idea of an anointed python version is front-loaded and everything else flows from there. I think it captures everything we talked about.

Putting it for review by maintainers and merging by next week if no real blockers.

[fenekku]

This is the only part I am personally more ambivalent about, because it makes the cutoff version implicit.

• ✔️ 1 less thing to keep up-to-date.
• ❌ uv/pkg managers can't use that info to provide appropriate python-version-supporting package version to client

Alternative there would be to put the lowest official version by default and replace it by lowest anointed version if any anointed version specific features are used (I don't think we should be any more granular than this).

[Samk13]

I see the maintenance argument, but I share some of your concerns here.

One thing requires-python gives us today is a machine-readable compatibility contract that packaging tools can use during dependency resolution.
Without it, users on unsupported versions may end up installing a package successfully and only discover incompatibilities later when running tests or the application itself.

I agree that maintaining exact compatibility markers can become a bit burdensome, especially if the policy is to support a moving set of "anointed" versions. However, I wonder if there is a middle ground where we keep a conservative lower bound (e.g. the oldest officially supported version) while avoiding upper bounds and frequent updates. That would still provide useful metadata to tooling without requiring us to encode the full support matrix in package metadata.

Could you elaborate a bit more on why the loss of packaging-tool support is considered an acceptable trade-off here?

[fenekku]

My understanding of @slint arguments on this was: require-python (and equivalent) would add maintenance cost and would potentially unnecessarily cutoff lower Python versions than the anointed one (and I think I even heard something akin to: it would cutoff package users not even using an official Python version anymore). To flesh out the cutoff argument: by not having it, packages that are still compatible with lower Python versions than the anointed would still be installable, and only incompatible ones would have to be forked. It's a "as permissive as possible" approach.

I think for me the higher priority goal would be to focus on delivering a piece of software built on top of/relying on supported software as much as possible. Obviously not all our package dependencies are maintained, but big ticket items like Python, the database, the web servers, docker are important. The legacy-compatibility objective would in effect be achieved to a lesser degree this way: folks who don't want to upgrade anything can keep using the old stuff and it should keep running with all the compatible old stuff. Problems mostly arise when folks do partial upgrades, and then I would argue they need to partially downgrade or move to the new version wholesale.

Even just having the require-python be >= <lowest official Python version> would be fine by me. Using the anointed version when we know nothing below is compatible would be even nicer.