OG-Core Python version support policy

[rickecon]

I propose that OG-Core and its respective country calibration repositories follow a Python version policy. My proposed Python version policy is the following:

• OG-Core only supports a maximum of two Python versions at a time.
• The two Python versions that we support are the two most recent versions that are out of the "bugfix" stage as defined by the "Status of Python Versions" page in the Python Developer's Guide.
  • If you look at the "Status of Python Versions" page, the two most recent versions of Python out of the "bugfix" stage as of August 2025 are Python 3.11 and 3.12.
  • If the schedule holds on the "Status of Python Versions" page, this means that we would update the OG-Core supported Python versions to 3.13 and 3.12 (dropping 3.11 support) sometime around Mar.-Apr. 2026, when Python 3.13 emerges from the "bugfix" stage.
• We should strictly limit the lower bound and upper bound of the Python version to those two versions in the following files:
  • the ogcore-dev conda environment environment.yml
  • ogcore package setup requirements setup.py
  • pyproject.toml
  • README.md package tags
  • intro.md Introduction page of the book package tags
  • build_and_test.yml Pytest CI testing
• We should set the actions in the following files to the most recent "out-of-bugfix" version of Python in the following files:
  • deploy_docs.yml GitHub Action
  • docs_check.yml GitHub Action
  • publish_to_pypi.yml GitHub Action

cc: @jdebacker

[jdebacker]

@rickecon I think we want to offer support for the default python version downloaded from Anaconda.org since we recommend installing that distribution.

Given time to run tests etc, I'm fine limiting that to two versions. I don't have strong preferences on the deployment of docs so long as they build (which is tested).

[rickecon]

@jdebacker. The "What's New in Python 3.13" page says:

Python 3.13 is the latest stable release of the Python programming language, with a mix of changes to the language, the implementation and the standard library. The biggest changes include a new interactive interpreter, experimental support for running in a free-threaded mode (PEP 703), and a Just-In-Time compiler (PEP 744).

That description of being "the latest stable release" might be what we should look for. I would rather have a Python version policy based on Python's descriptions rather than Anaconda's. And conda is excellent at installing environments with Python versions that are higher than the version that comes in the base conda environment. If fact, that version in the base environment is limited by all the requirements of all the other packages in that base environment.

In summary, let's just choose a rule that allows us to currently switch to Python 3.12 and 3.13, and we can follow that rule across our repositories. The rule could be something like using the latest two stable versions.