Release checklist
Releases are tagged on main. Tagging v* triggers the build job of the
Publish workflow, which uploads the wheel and sdist as a workflow artifact; the
PyPI upload is a separate, manual step (see Post-release and Deployment).
Pre-release
Green main.
mainpasses lint, type check, tests (Python 3.10–3.12), the documentation build, and the security scan.Changelog finalised. Move the accumulated
[Unreleased]entries under a new[X.Y.Z] - YYYY-MM-DDheading and leave a fresh[Unreleased]section.Version bumped. Update
versioninpyproject.tomltoX.Y.Z.Examples verified. The OpenFAST examples import against the current public API, and
examples/synthetic_quickstart.pyruns end to end.Docs build clean.
sphinx-build -W -b html docs docs/_build/htmlsucceeds.Validation matrix current. Validation matrix reflects the shipped behaviour.
Cutting the release
Land the changelog finalisation and version bump on
mainthrough a normal pull request, and wait for all checks to pass.Tag the release commit on
mainasvX.Y.Zand push the tag (for example by publishing a GitHub release, which creates the tag).
Post-release
Confirm the
Publishworkflow’s build job produced the wheel and sdist artifact for the tag.When the upload is intended, run the
Publishworkflow manually (workflow_dispatch), selecting the release tagvX.Y.Zas the ref (“Use workflow from → Tags → vX.Y.Z”), so it builds and uploads exactly the tagged commit rather than whatever the default branch currently points at. Tagging alone does not upload, and this requires PyPI trusted publishing to be configured.Confirm the documentation built without warnings.
Open a GitHub release with the changelog section as the notes.
Versioning
VANE follows Semantic Versioning. During the
alpha series the API may change between minor versions; from the first tagged release,
breaking changes increment the major version (or the minor version while
0.y.z), and are always recorded in the changelog.