Topic
Everything filed under release-engineering, across every section.
A release tag is a dependency contract, not a label your team can casually move. Learn how GitHub tag-targeting rulesets prevent tag rewrites, where GitHub Releases fit, and how to scope an immutable-tag policy without blocking legitimate development tags.
A Git tag, a GitHub prerelease, and the Latest badge answer three different questions. Use this release engineering workflow to decide when to tag a commit, publish a prerelease, promote stable builds, and explain why tag and release dates differ.
Turn a tagged build into a reproducible GitHub Release: upload one immutable build bundle as a workflow artifact, attach that exact bundle to the release, then download and checksum the published asset as a consumer would.
Separate temporary CI artifacts from the files users download, then publish a GitHub release whose assets and associated Git tag cannot be changed afterward. This checklist covers build promotion, checksums, release workflows, and the operational tradeoffs of immutability.
A protected tag can stop a version name from being moved, while an immutable release protects the published package and its associated tag after publication. Learn where each control begins and ends, and how to combine them in a practical GitHub release workflow.
GitHub’s legacy tag-protection rules were migrated to tag rulesets after scheduled API brownouts in 2024. Use this checklist to translate patterns and permissions, create or audit repository rulesets through the supported path, and verify that release tags still point to the intended commits.