Compatibility and support¶

This page makes the current support story explicit for adopters and contributors.

Support summary¶

Area	Current status	Source of truth
Python runtime	`3.10`, `3.11`, `3.12` supported	`pyproject.toml` and CI matrix
Behave dependency	`behave>=1.3.3`	`pyproject.toml`
Operating systems validated in CI	Ubuntu and Windows	`.github/workflows/ci.yml`
Static analysis baseline	Python `3.10` on Ubuntu	`.github/workflows/ci.yml`
Docs build baseline	Python `3.10` on Ubuntu	`.github/workflows/docs.yml` and release verification

Python versions earlier than 3.10 are not supported by the current release line.

What CI validates today¶

The repository currently validates:

static analysis (mypy, pylint, compileall) on Ubuntu with Python 3.10
unit tests on Ubuntu and Windows with Python 3.10, 3.11, and 3.12
Sphinx documentation builds on Ubuntu with Python 3.10
release verification on the release tag with Python 3.10

That means support is not just declared in packaging metadata; it is also exercised continuously in GitHub Actions.

Behave version expectations¶

The package declares behave>=1.3.3.

In practice, CI installs the current resolver-selected Behave release that satisfies that requirement on each supported Python version. The project does not currently publish a separate exhaustive Behave-version matrix beyond that declared minimum.

If your own suite needs a tighter Behave pin, keep that pin in the downstream consumer project and validate it there.

Documentation toolchain on Python 3.10+¶

The main docs and the generated step-doc flow are available from the same pip install behave-toolkit command.

On Python 3.10, packaging resolves a Python-3.10-compatible documentation stack automatically. On Python 3.11+, newer Sphinx releases are used.

The key point for users is simple: the docs workflow and generated-docs commands are part of the supported experience on the same Python range as the runtime helpers.

How support changes should be communicated¶

Any future support change should update all of the following together:

project.requires-python in pyproject.toml
Python classifiers in pyproject.toml
the CI matrix in .github/workflows/ci.yml
the docs workflow and release verification workflow if needed
this page and the release notes / changelog

Support should never change silently in metadata alone.

Local verification commands¶

The repository uses these validation commands locally and in CI:

python -m unittest discover -s tests -v
python -m mypy src tests test_support.py
python -m pylint src tests test_support.py
python -m compileall src tests test_support.py
python -m sphinx -W --keep-going -b html docs docs/_build/html

If you are evaluating compatibility in a downstream project, run the relevant subset of those checks in the Python and Behave versions you care about.