Skip to content

Maintainer release checklist

This repository is released by the maintainer as needed. Pushing a release tag triggers the Release workflow, which publishes to PyPI once the build passes; ordinary branch commits and manually dispatched workflow runs only build and check, they do not publish. The tag must be vMAJOR.MINOR.PATCH, the version must match the package, and the commit the tag points to must already be on main.

Before the release

  1. Wrap up the changes and review the diff. Make sure CHANGELOG.md states user-visible changes, source limitations and migration notes; private-lake measurements and run logs stay in private/ and must not go into the package or the public docs.
  2. Sync the release version in pyproject.toml, src/cnequity/__init__.py, CITATION.cff and server.json (both the top level and packages[0]). Generate the contract with cne contract show --out contracts/v<version>.json; for incompatible changes, document the change, migration and rollback in contracts/migrations/<version>/, and update the in-package contract list and the corresponding tests. Do not create the release tag before the version change is complete.
  3. In an isolated temporary lake, verify common commands such as cne init --profile sample, cne query --sql "SELECT 1" and cne status --datasets. Record real-source reachability and local lake coverage separately; if a source is rate-limiting or refusing access, do not mask it with a retry storm, and do not use the result to claim that whole-market data is complete.
  4. Run CI's quality, offline test, frontend and docs checks locally, plus the Release workflow's contract comparison, restore drill, sdist/wheel checks and clean-environment wheel smoke test. The network-dependent security audit is run by the workflow; all check results should be for the same commit that is being released.
  5. Merge the commit to be released into main and confirm that the CI and security workflows pass. Verify that the GitHub pypi environment only allows deployments from release tags; if you want a manual review, configure a required reviewer. The PyPI Trusted Publisher should trust only this repository's Release workflow and that environment.

Release

Create and push the release tag on the verified main commit. Confirm that the Release workflow's build, contract and publish jobs all pass, then check the version and description on the PyPI page and cne --version after installation. Once published, the tag and the PyPI files must not be treated as rewritable drafts; if a problem is found, publish a fix release and explain the impact.

Once the release is live on PyPI, register the same version with the MCP Registry: install mcp-publisher, run mcp-publisher login github in the repository root (authorizing as the rootSunc account), then run mcp-publisher publish. The Registry verifies package ownership through the mcp-name: io.github.rootSunc/cnequity comment in the PyPI description. That comment sits at the end of README.md and is carried into README.pypi.md by the sync script; do not remove it.

Day to day, only one stable release entry point needs to be maintained. Multiple Python versions and platforms are covered by the CI matrix; the Release workflow reruns the key offline regressions once so that the tag and build artifacts actually released have independent evidence. There is no need to repeat the whole matrix manually for each release. Approval for the pypi environment and tag protection are GitHub repository settings, not part of this workflow file; the maintainer must verify them in the repository settings.