A release is a saved, named version of your app that you can point people at, and GitHub makes it easy to ship one with a summary of exactly what changed. Coupled with version numbers that mean something, releases let users understand the risk of an upgrade before they take it.
About 2 min of reading
I shipped a version and nobody knew what changed, then a bug slipped in that users did not expect. Let me tag a version, write honest release notes, publish the release, and tell people so they can judge the risk before they upgrade.
Tag a commit as a release so it becomes a named point in time you can travel back to. A tag is a lightweight label pointing at a commit, and anyone can check out that exact version months later and reproduce it. Tagging is what turns "some code at this moment" into a releasable version.
Before you run it, say out loud what it will print. Then open the answer.
Write release notes that tell users what changed before they open it, including the downsides. A short honest list, including anything they should watch out for, earns more trust than a generic "bug fixes" line and lets users judge the risk of upgrading.
Before you run it, say out loud what it will print. Then open the answer.
Publish the release. Publishing attaches the tag to a named version in the GitHub UI, so users can find it, read the notes, and travel back to it later. It becomes a downloadable point in time, not just a commit hash anyone has to remember.
Before you run it, say out loud what it will print. Then open the answer.
Let people know the release exists. Users who are on an old version now have a page to look at, notes to read, and a decision to make. A small note to your community closes the loop from "we shipped" to "they found out".
Before you run it, say out loud what it will print. Then open the answer.
Read the version numbers like a warning sign before upgrading. Semantic versioning uses three numbers, major.minor.patch, and each one tells you how risky a release is. A patch feels safe, a minor adds features, a major means "get ready, things may break".
Before you run it, say out loud what it will print. Then open the answer.
Use X.Y.Z. Bump Z for small fixes, Y for new features, X for breaking changes. The numbers tell users how risky a release is before they open it.
Give each release clear notes. Users love knowing what changed before they download, and a short honest list, including anything they should watch out for, is more useful than a generic "bug fixes" line.
Release v1.2.0
- Added a login page
- Fixed the search bug
- Slower page load on mobileEach release gets a tag like v1.2.0, and you can always travel back to it later. Users know in advance what the release contains, including the downsides, being honest about a regression earns more trust than hiding it.
git tag -a v1.2.0 -m "Login + search fixes"
git push origin --tagsA tag marks a specific commit as a release. It's a lightweight label that points at a version, and it becomes a downloadable point in time. Anyone can check out v1.2.0 months later and reproduce it exactly.
1.0.0 -> 1.0.1 : a small bug fix (patch)
1.0.0 -> 1.1.0 : a new feature (minor)
1.0.0 -> 2.0.0 : a breaking change (major)Semantic versioning uses three numbers, major.minor.patch, and each position means something. Users read them to judge risk: a patch feels safe, a minor adds features, a major means "get ready, things may break." Following the convention makes your releases self-explanatory.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.