Add automatic patch-bump releases on push to master

[Copilot]

Adds a GitHub Actions workflow that automatically tags and releases on every push to master using a simple patch-bump strategy. No prior release automation existed.

Workflow changes (.github/workflows/release.yml)

• New bump-and-release job — triggers on push: branches: master:
  • Fetches full history and tags (fetch-depth: 0)
  • Finds the highest existing v*.*.* tag (strict ^v[0-9]+\.[0-9]+\.[0-9]+$ filter — skips pre-release/malformed tags)
  • Falls back to v0.1.0 if no prior tag exists; otherwise increments patch
  • Pushes the new tag and creates a GitHub Release with autogenerated notes via softprops/action-gh-release@v2
• Preserved build-and-publish job — unchanged; still triggers on manual v*.*.* tag pushes for PyPI

latest_tag=$(git tag --list 'v*' --sort=-version:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1)

Docs (README.md)

Added a Releases section covering the patch-bump behavior, the v0.1.0 bootstrap default, and two key caveats:

• Minor/major bumps require a manually pushed tag before merging
• Auto-created tags use GITHUB_TOKEN, so they do not re-trigger the PyPI publish job (by GitHub Actions design)

Original prompt

Add GitHub Actions-based automatic releases for the repository uscient/mboxer using the simplest strategy: on every push to the master branch, compute the next patch version tag, create and push that Git tag, and publish a GitHub Release with autogenerated release notes.

Requirements:

• Repository: uscient/mboxer
• Implement only the simple patch-bump strategy.
• Trigger on pushes to master.
• Use appropriate workflow permissions to create tags and releases.
• Ensure checkout fetches tags/history needed to calculate the latest version tag.
• If no prior v* tags exist, start from v0.1.0.
• If prior tags exist, increment the patch component of the highest semantic version tag matching v*.
• Create a GitHub Release from the new tag.
• Prefer a straightforward implementation in .github/workflows/release.yml.
• Add or update documentation briefly so maintainers know what the workflow does and any assumptions/caveats.

Implementation notes:

• Avoid introducing additional release strategies or tools.
• The workflow should be safe and clear for a Python repo but does not need to publish packages.
• Mention that the workflow runs on any push to master, which is effectively merged PRs if branch protection requires PR-only changes.
• If needed, update README or add a short docs section describing the behavior.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Can I have auto releases with version tagging on a successful merge with master branch?

Assistant: Yes — you can automate this with GitHub Actions so that when changes land on master, GitHub creates a tag and a release.

What GitHub gives you out of the box:

• PRs can auto-merge when checks pass: Managing auto-merge for pull requests in your repository
• Releases can have auto-generated notes: Automatically generated release notes

What GitHub does not do automatically by default:

• It does not automatically bump your version, create a Git tag, and publish a release just because master received a merge.
• You implement that behavior with a workflow triggered on pushes to master.

Typical setup

1. Trigger a workflow on:
   • push to master
2. In the workflow:
   • determine the next version
   • create/push a tag like v1.2.3
   • create a GitHub Release from that tag
   • optionally generate release notes automatically

Example workflow

name: Release on master merge

on:
  push:
    branches:
      - master

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Calculate next version
        id: version
        run: |
          latest_tag=$(git tag --list 'v*' --sort=-version:refname | head -n 1)
          if [ -z "$latest_tag" ]; then
            next="v0.1.0"
          else
            version=${latest_tag#v}
            IFS='.' read -r major minor patch <<< "$version"
            next="v$major.$minor.$((patch + 1))"
          fi
          echo "next=$next" >> $GITHUB_OUTPUT

      - name: Create tag
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git tag ${{ steps.version.outputs.next }}
          git push origin ${{ steps.version.outputs.next }}

      - name: Create GitHub release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ steps.version.outputs.next }}
          generate_release_notes: true

Notes

• This example bumps only the patch version.
• If you want proper semver based on commit messages or PR labels, use a release tool like:
  • Release Please
  • semantic-release
  • Python Semantic Release
• Since your repo is Python-only, python-semantic-release is a strong fit if you want versioning tied to conventional commits.

Recommended approach for uscient/mboxer

• If you want simple automation: use the workflow above.
• If you want clean semantic versioning and changelogs: use a semantic release tool plus GitHub’s generated release notes config in .github/release.yml, as documented here: Automatically generated release notes

Important caveat

• push to master fires for any push, not only merged PRs. If you want “successful merge to master” specifically, that’s usually fine if branch protection requires PR merges only.
• If direct pushes are allowed, this workflow will also release on those pushes.

If you want, I can...

This pull request was created from Copilot chat.