Tiger Release

TIGER Release

Use this skill for end-to-end changes that must reach both the TIGER repository and the graph-tiger package. A release is complete only when the merged source, documentation, hosted Read the Docs site, version metadata, GitHub release, and PyPI artifacts agree.

Publishing, merging, tagging, and creating releases are external mutations. Perform them only when the user explicitly authorizes the corresponding action.

Inspect before editing

Read the current versions of:

• setup.py
• CHANGELOG.md
• docs/source/conf.py
• .readthedocs.yaml
• .github/workflows/ci.yml
• .github/workflows/cd.yml
• the affected production module, tests, API documentation, tutorial, README section, and bibliography entries

Check the latest GitHub release and the versions already present on PyPI. PyPI files are immutable: never reuse a published version.

For correctness changes governed by tiger-correctness-remediation, read and follow that skill as well.

Keep the change synchronized

A public behavior change normally requires all of the following in the same feature branch:

1. Update the production implementation without unrelated reformatting.
2. Add deterministic regression tests for the scientific or API contract.
3. Update the affected docstrings and docs/source API page.
4. Update a tutorial or runnable example when users need new parameters or outputs.
5. Update the README when the public model or technique inventory changes.
6. Add or correct literature entries in docs/source/refs.bib when the implementation follows a published method.
7. Add a concise entry under the current changelog release section.

Documentation must describe the code that will actually ship. State initialization, update order, randomness, mutation policy, outputs, edge cases, and model-specific conventions when they affect results. Do not claim fidelity to a named method without tests for its defining behavior.

Choose and set the version

Use semantic versioning relative to the latest published package:

• Patch release for backward-compatible fixes.
• Minor release for a new public model, parameter, output, or other backward-compatible feature.
• Major release for intentional breaking API or behavior changes.

Before merge, update every active version source:

• version = "<version>" in setup.py
• release = '<version>' in docs/source/conf.py
• Replace ## Unreleased in CHANGELOG.md with a descriptive heading beginning ## <version>

Search the repository for the previous version and inspect every match. Update only values that represent the current package or documentation release; retain historical changelog entries and old-version examples when they are intentionally historical.

Validate the release candidate

Run or confirm all of the checks encoded by .github/workflows/ci.yml:

• Core tests across the supported Python matrix.
• Optional visualization tests.
• python -m build.
• python -m twine check dist/*.
• Install the built wheel in a clean location and import graph_tiger.
• Build the Sphinx HTML documentation using the dependencies and configuration declared in .readthedocs.yaml.

Review the complete PR diff and changed-file list. Confirm that package data, imports, citations, examples, and changelog statements match the implementation. Do not merge while any required job is pending or failing.