GitHub Releases

A GitHub Release represents a published version of a project on GitHub. It can describe what changed in that version and provide files for users to download.

Source Code
     ↓
Git Tag
     ↓
GitHub Release
     ↓
Release Notes + Assets

Releases help developers communicate stable or significant versions of their software.

• Publish project versions
• Write release notes
• Provide downloadable files
• Identify specific versions
• Communicate changes
• Organize software distribution

A GitHub Release is commonly associated with a Git tag.

Commit
  ↓
Tag v1.0.0
  ↓
GitHub Release
  ↓
Version Information

The tag identifies the Git commit associated with the release.

Projects often use version numbers to identify different releases.

v1.0.0
v1.1.0
v1.2.0
v2.0.0

A project's versioning convention should be consistent and clearly communicated to users.

A common versioning format is Semantic Versioning, which uses three main numbers:

MAJOR.MINOR.PATCH

Example:

2.4.1

• MAJOR – incompatible API changes
• MINOR – backward-compatible functionality
• PATCH – backward-compatible bug fixes

A tag can be created locally to identify a specific commit.

git tag v1.0.0

This creates a tag named v1.0.0 pointing to the current commit.

Annotated tags contain additional information such as the tagger, date, and message.

git tag -a v1.0.0 -m "Version 1.0.0"

Annotated tags are useful when marking important project versions.

Use the following command to list tags in a local repository:

git tag

Example output:

v1.0.0
v1.1.0
v2.0.0

The git show command can display information about a tag.

git show v1.0.0

For an annotated tag, this can show tag information and the commit associated with it.

A local tag can be pushed to a remote repository.

git push origin v1.0.0

After the tag is available on GitHub, it can be associated with a GitHub Release.

Multiple local tags can be pushed using:

git push origin --tags

This pushes local tags that are not already present on the remote.

A release can be created from the GitHub repository's release management area.

Repository
    ↓
Releases
    ↓
Create New Release
    ↓
Choose Tag
    ↓
Add Release Information
    ↓
Publish Release

A release can have a clear title describing the published version.

Version 1.0.0
Student Management System v2.0

A descriptive title helps users quickly identify the release.

Release notes describe the important changes included in a version.

## What's New

- Added student login
- Added attendance report
- Improved dashboard

## Bug Fixes

- Fixed login validation
- Fixed report calculation

Release assets are downloadable files attached to a release.

Examples include:

• ZIP files
• Application installers
• Compiled programs
• Documentation packages
• Build artifacts

GitHub provides source-code archives associated with repository versions. Users can download the source corresponding to a release tag.

Release v1.0.0
      ↓
Source Code
      ↓
Download Archive

A draft release can be prepared before it is published publicly as a release.

Prepare Release
      ↓
Write Notes
      ↓
Add Assets
      ↓
Review
      ↓
Publish

Drafts are useful when release information still needs preparation.

A pre-release can indicate that a version is not intended to be treated as the final stable release.

v2.0.0-beta
v2.0.0-rc.1

Pre-release versions can be useful for testing and early feedback.

A useful release note can organize changes into clear sections.

## Features
- New login system

## Improvements
- Faster dashboard

## Bug Fixes
- Fixed logout issue

## Documentation
- Updated setup guide

Releases can provide a convenient place for users to find versions of software and related downloadable files.

Version
  ↓
Release
  ↓
Notes
  ↓
Download Files
  ↓
Users

Develop
   ↓
Test
   ↓
Commit
   ↓
Create Tag
   ↓
Push Tag
   ↓
Create Release
   ↓
Write Release Notes
   ↓
Add Assets
   ↓
Publish

git switch main

git pull

git status

git tag -a v1.0.0 -m "Version 1.0.0"

git push origin v1.0.0

After pushing the tag, the corresponding version can be published as a GitHub Release.

Multiple releases can represent the evolution of a project.

v1.0.0
  ↓
v1.1.0
  ↓
v1.2.0
  ↓
v2.0.0

Each release can identify a particular version of the project.

A project may maintain a changelog describing changes across versions. Release notes can also summarize changes for a specific release.

Version 1.2.0
--------------
Added:
- New dashboard

Changed:
- Improved login

Fixed:
- Report bug

• Use consistent version numbers.
• Create releases from tested code.
• Write clear release notes.
• Describe important changes.
• Include useful downloadable assets.
• Identify pre-release versions clearly.
• Verify the correct tag before publishing.
• Keep release information organized.
• Test downloadable files.
• Communicate important breaking changes.

• Using confusing version numbers.
• Creating a release from the wrong tag.
• Publishing untested software.
• Writing incomplete release notes.
• Uploading the wrong asset.
• Forgetting to push the required tag.
• Not identifying pre-release versions clearly.
• Not communicating important changes.

Project:
Student Management System

Release:
v2.0.0

Features:
- Student admission
- Attendance system
- Fee management

Bug Fixes:
- Fixed login issue
- Fixed fee calculation

Asset:
student-management-v2.0.0.zip

• Complete the planned features.
• Review the source code.
• Run tests.
• Verify the correct branch.
• Create the correct Git tag.
• Push the tag.
• Prepare release notes.
• Prepare downloadable assets.
• Check the version number.
• Publish the release.

Repository: my-project

Tag:
v1.5.0

Title:
My Project 1.5.0

Release Notes:

## Features
- Added user dashboard
- Added search functionality

## Improvements
- Improved performance

## Bug Fixes
- Fixed login error

Assets:
my-project-1.5.0.zip

GitHub Releases provide a convenient way to publish specific versions of a project. Releases can be connected to Git tags and can include release notes and downloadable assets.

Code
 ↓
Test
 ↓
Tag
 ↓
Release
 ↓
Release Notes
 ↓
Assets
 ↓
Users

A consistent release process makes it easier for developers and users to understand project versions and obtain the appropriate software.