| title | Release Resources and Template |
|---|
Releases are the mechanism for packaging a set of features, bug fixes, and other modifications to a software repository. This page provides information about compiling (tagging) a release and its release notes, as well as examples and other web resources on this topic.
GitHub releases are driven by version tags (e.g., v1.0) applied to a set of commits.
- Look at your repo's release history and determine the appropriate incremental number (i.e., semantic versioning) to assign to the new release. The typical nomenclature is
major.minor.patchwherepatchis optional. Ex:v1.2orv1.2.1 - View a log of your commit history. Ex:
$ git logor$ git log --pretty=oneline - Decide which commits to include in the release.
- Apply the version tag to the last (most recent) commit's checksum. Ex:
$ git tag -a v1.0 4c73e1- This action will prompt you to enter a message corresponding to the tag. Ex:
News templates
- This action will prompt you to enter a message corresponding to the tag. Ex:
- Confirm the commit tagged for the release. Ex:
$ git show v1.0 - Push tag(s) to
originorupstreamas appropriate. Ex:$ git push origin v1.0or$ git push upstream --tags - View your releases under your repo's Code tab, which lets you toggle between Releases and Tags. This is where the message from step 3 appears. Ex: this repo
GitHub allows you to draft release notes directly in the UI. The steps are straightforward:
- Start a new draft release.
- Define its corresponding version (tag) number and branch.
- Give the release a title and description.
- Publish the release. Ex: this repo v1.2
Note: Be as clear as possible in your release notes so users know what they're getting. Ideally, this means each commit message is unique and direct. You may also want to organize your notes into categories or separate them with headings such as Enhancements, Bug Fixes, Deletions, etc. to help users navigate a long list of changes or highly detailed notes.