Skip to content

Latest commit

 

History

History
58 lines (33 loc) · 2.45 KB

File metadata and controls

58 lines (33 loc) · 2.45 KB

Releasing new versions of pre-commit-macadmin

Releases are largely automated via GitHub Actions. The workflow triggers when setup.py is pushed to main, creating a GitHub release and automatically preparing the dev branch for the next release.

Release Process

  1. On the dev branch, check unit tests:

     .venv/bin/python -m coverage run -m unittest discover -vs tests
    
  2. Prepare CHANGELOG.md for release by moving [Unreleased] changes to a new version section:

     ## [Unreleased]
    
     Nothing yet.
    
     ## [X.Y.Z] - YYYY-MM-DD
    
     ### Added/Changed/Fixed/Removed (separate sections as applicable)
     - New features, changes, fixes, or removals
    

    The release workflow will extract this section for the GitHub release notes.

  3. Add the version comparison link at the bottom of CHANGELOG.md:

     [X.Y.Z]: https://github.com/homebysix/pre-commit-macadmin/compare/vPREVIOUS...vX.Y.Z
    
  4. Update the version in setup.py to match the CHANGELOG version (e.g., 2.3.6).

  5. Update the version in README.md examples to match (e.g., rev: v2.3.6).

  6. Commit these changes to dev and push.

  7. Merge dev branch to main.

  8. The release workflow will automatically:

    • Detect the version from setup.py (e.g., 2.3.6)
    • Create a GitHub release with tag v2.3.6
    • Extract release notes from CHANGELOG.md
    • Merge main back to dev
    • Bump dev versions to the next patch version (e.g., 2.3.7) in setup.py and README.md
    • Commit and push the updated version to dev

    Note: CHANGELOG.md is NOT automatically updated on dev. Add entries to the [Unreleased] section as you make changes.

  9. Pull the updated dev branch to continue development at the new version.

  10. As you make changes, add entries to the [Unreleased] section of CHANGELOG.md. When ready for the next release, simply promote those changes to a new version section (repeat from step 2) - no need to manually bump versions unless you want to change to a minor or major version.

  11. After each release, verify on GitHub and run pre-commit autoupdate on a test repo to confirm it updates correctly.

Version Numbering

The workflow automatically bumps the patch version (X.Y.Z → X.Y.Z+1). If you need to bump the minor or major version, manually update the version numbers in setup.py, README.md, and CHANGELOG.md before merging to main.

Pre-releases

If a pre-release is desired for testing purposes, it must be done manually.