- Clearly identify versions (e.g., v1.0.0, v2.1.3)
- Distribute binaries and assets
- Publish detailed release notes and changelogs

Prerequisites
- GitHub CLI (
gh) installed and authenticated (gh auth login). - A Git repository with commits you want to release.
1. Creating a Release Tag with GitHub CLI
Use thegh release create command to generate a Git tag and corresponding GitHub Release.
Basic syntax:
v1.0.0 Git tag and the GitHub Release entry.
If this is your first time using the GitHub CLI, run
gh auth login to authenticate.1.1 Adding a Title and Release Notes
To provide context, include a title and detailed notes:| Flag | Description | Example |
|---|---|---|
| —title | Sets the release title | --title "Initial Release" |
| —notes | Supplies the body of the release notes | --notes "Bug fixes and performance updates" |
| —draft | Marks the release as a draft | --draft |
| —prerelease | Designates the release as a pre-release | --prerelease |
Once a tag is published as a public Release, avoid rewriting or deleting it—immutable tags preserve release integrity.
2. Understanding Semantic Versioning
Semantic Versioning (SemVer) is a widely adopted specification for version numbers in the form MAJOR.MINOR.PATCH. It clarifies how version numbers change with each type of update:| Version Segment | When to Increment | Example Change |
|---|---|---|
| MAJOR | Incompatible API changes | 1.0.0 → 2.0.0 |
| MINOR | Backwards-compatible functionality additions | 1.1.0 → 1.2.0 |
| PATCH | Backwards-compatible bug fixes and performance tweaks | 1.0.0 → 1.0.1 |
Refer to the SemVer specification for detailed guidelines on version numbering.
3. Links and References
4. Example Workflow
- Commit your changes:
- Create and push a new tag with Release:
- Verify on GitHub under Releases to confirm the entry and assets.