Release Workflow - PyCharter
Description: Data Contract Management, ETL Pipelines, and Quality Assurance for Python

Skip to content

# Release workflow

Releases are driven by version tags on `main`. Pushing a tag runs tests, builds the package, publishes to PyPI, and creates a GitHub Release.

## One-time release steps

1. Merge develop into main and ensure CI is green.
2. From main, create and push a tag (replace `0.0.33` with your version):

    git tag v0.0.33
    git push origin v0.0.33

1. The workflow runs automatically. When it finishes:
2. The package is on PyPI (e.g. `pip install pycharter==0.0.33`).
3. A GitHub Release exists for that tag.

No need to edit `pyproject.toml` for the version unless you want the repo’s version to match the release.

## Using the release script

To bump the version in the repo, commit, tag, and push in one go:

    ./bin/release.sh 0.0.33

See `bin/README.md` for options (e.g. `--dry-run`, `--no-release`). The script creates the tag; the workflow still uses the tag as the source of truth for the version published to PyPI.

## Verify

After the workflow completes:

1. Actions: `https://github.com/$OWNER/pycharter/actions`
2. PyPI: https://pypi.org/project/pycharter/
3. Install: `pip install pycharter==0.0.33`

## Notes

- Tag format: `v` plus semantic version (e.g. `v0.0.33`). The workflow strips the `v` for the package version.
- Releasing is from main only. Develop is for integration; main is for releases.