Maintainer notes¶

Working agreements live in AGENTS.md; this page holds the procedures.

Releasing¶

Releases publish to PyPI via Trusted Publishing — no tokens.

Stamp the version: set version in pyproject.toml (drop the .dev suffix) and retitle the [Unreleased] changelog section, on main.
gh release create vX.Y.Z --title "orlab X.Y.Z" --notes ...
release.yml gates on just check && just test, builds with uv build, refuses a dist whose version doesn't match the tag (or any pre-release string), and publishes. Then bump main to the next .dev0.

Manual fallback: workflow_dispatch on any ref containing the workflow, with the exact expected_version as input.

Supporting a new OpenRocket release¶

One PR:

uv run python tools/generate_profile.py <new jar> — reflects the jar and verifies the contract manifest (fails loudly, naming missing members, if the jar breaks anything orlab touches).
uv run python tools/generate_enums.py — regenerates the union enums.
Register the new module in src/orlab/profiles/__init__.py and add the version + sha256 to src/orlab/_pins.py and the CI matrix in ci.yml (the integration suite and fetch_jar both read the pins; changing _pins.py also rolls the CI jar caches).
just test && just test-integration.

Until that PR lands, the new release runs on the nearest older profile (the monthly canary.yml run exercises exactly this path against the newest upstream release and opens an issue on failure). OpenRocketInstance.profile_exact is False throughout — the canary does not assert the flag, it runs on it.

Test tiers¶

just test — unit suite, jar-free, sub-second; runs on every push and PR (CI test matrix) and gates every release build.
just test-integration — real simulations against every supported jar (sha256-pinned, cached in ~/.cache/orlab-jars or $ORLAB_JAR_CACHE); ORLAB_TEST_VERSION=24.12 limits to one version, as the CI matrix does.