Git Release Workflow

Goal

Define a repeatable “this commit is a release” practice.

Why

Build pipeline; framework Software Product Essentials.

When something is a release

A release is not “main is green.” It is an explicit decision:

  1. Version number chosen (SemVer/CalVer per project policy)

  2. Changelog updated (timeline + detail page when you use that style)

  3. Tag created (v1.2.3)

  4. CI publishes artifacts for that tag

  5. Optional: package managers / update feed updated

Suggested flow

  1. Finish work on a branch → review → merge to main

  2. On main: bump version files if not automated

  3. Write changelog entry (what users care about, not every commit)

  4. Tag annotated release: git tag -a v1.2.3 -m "v1.2.3"

  5. Push tag → CI builds, tests, signs, uploads

  6. Verify About/--version on the artifact matches the tag

  7. Announce / promote channel (beta → stable) when ready

Channels

  • nightly/dev — optional daily tags or trunk artifacts

  • beta — pre-release tags (v1.2.3-beta.1)

  • stable — plain version tags

Stamp the channel into build info so About and updaters agree.

Do not

  • Ship laptop-only binaries as the official build

  • Move tags after people may have downloaded them

  • Skip checksums on public desktop artifacts

Related