Version Bumping

~9 min · versioning, semver, automation

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Make versioning a workflow, not a chore

Manually editing a version string in pyproject.toml / package.json / Cargo.toml on every release is forgettable and error-prone. Automate it.

Approaches

1) Conventional Commits + automated bump

Commits follow feat: ..., fix: ..., feat!: ... shapes.
A tool (release-please, semantic-release) reads the commit log and decides patch / minor / major.
The bump PR (or commit) updates the version + changelog + creates the tag.

2) Manual workflow_dispatch with a 'kind' input

Trigger a release workflow with input kind: choice [patch, minor, major].
Workflow runs npm version $kind / uv version --bump $kind, commits, tags, pushes.
Less ceremony than Conventional Commits; more human discretion.

3) Calendar versioning (CalVer)

Use the date as the version: 2026.04.30.
No bump decision; the next release on a new day is automatically newer.
Best for products with no semver-style API contract.

Code

Manual workflow_dispatch bump·yaml

name: bump
on:
  workflow_dispatch:
    inputs:
      kind:
        type: choice
        options: [patch, minor, major]
        default: patch
permissions:
  contents: write

jobs:
  bump:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0, token: ${{ secrets.GITHUB_TOKEN }} }
      - uses: actions/setup-node@v4
        with: { node-version: '22' }
      - name: Bump
        run: |
          git config user.email 'gha@bot'
          git config user.name 'gha bot'
          npm version ${{ inputs.kind }} -m 'chore(release): %s'
          git push --follow-tags

External links

Exercise

Pick a version-bumping strategy for one of your repos and implement it: either set up release-please, write a manual bump workflow, or document a clear CalVer policy. Apply it to one release and notice how much ceremony just disappeared.