GitHub releases vs tags: choosing software update signals

Which GitHub signal answers your question?

Start with the update decision

For most software users, published releases are the best starting signal: they provide a place for maintainers to explain changes and attach downloads. Tags are useful when a project publishes versions without GitHub releases. Notifications and Atom feeds deliver signals; they do not decide whether an upgrade fits your installation. Separate discovery from approval: first notice a candidate, then check compatibility, security relevance, and the supported release line. A quiet release feed alone cannot establish that your software is current.

A release adds context to a Git tag

GitHub documents releases as software iterations based on Git tags, which mark points in repository history. A release can add notes and attached binaries; GitHub also provides source ZIP and tarball links. A source archive is not necessarily a ready-to-install application. Tags can exist without releases: the Releases API explicitly excludes ordinary tags that have no associated release. Tag dates and release dates can differ, so avoid treating a tag timestamp as the publication time. Compare both tabs before choosing which signal represents this project’s distribution practice.

Choose notifications for an existing GitHub workflow

GitHub supports custom repository notifications for releases without requiring you to follow every issue and pull request. To configure this yourself, open the repository’s Watch menu, choose Custom, and select Releases. Then review your notification settings to ensure the intended delivery channel is enabled. Participating conversations and mentions can still generate other notifications. This suits someone already reviewing GitHub or email regularly. It is not a tag-monitoring substitute: a maintainer creating only a Git tag has not thereby published a release. Keep repository selection separate from account-level delivery settings when diagnosing missing messages.

Use Atom to collect release and tag signals

GitHub’s official cli/cli Releases page advertises two Atom feeds: https://github.com/cli/cli/releases.atom for release notes and https://github.com/cli/cli/tags.atom for tags. These provide concrete subscription addresses to evaluate in a reader. For another public repository, substitute its owner and repository name, then check that your reader accepts the feed and that entries link to the intended project. Use the release feed for release announcements and consider the tag feed where tags are the publication signal. Compare recent entries with the corresponding GitHub pages before relying on coverage. Check reader refresh timing, retention, and handling of edited entries separately.

Handle drafts, prereleases, and release lines explicitly

Saving a draft and publishing a release are different actions. GitHub’s Releases API documentation says only users with push access receive draft listings, so public monitoring should not expect early visibility into unpublished work. GitHub describes the prerelease option as indicating software that is not ready for production and may be unstable. Check that designation on the release page rather than assuming every feed item is suitable for production. Also read which branch or product line the update serves. A single latest-release shortcut is a poor inventory for installations that deliberately remain on an older supported line.

Record identity instead of trusting a version label

Tags should not be assumed permanently fixed merely because their names resemble version numbers. GitHub’s Git references API documents updating references to new SHAs. Restrictions can apply: its immutable-release documentation says an associated tag is locked to a commit and cannot be moved or deleted while that release exists. Immutable release assets are protected too, but titles, notes, and prerelease or latest status remain editable. Record the release link, tag, and resolved commit SHA when approving an update. Inspect the release’s Immutable indicator rather than inferring protection from a naming convention.

Read security advisories alongside release notes

A release announcement explains a software publication; a security advisory communicates a vulnerability. GitHub recommends publishing an advisory when a release fixes a vulnerability, and documents a separate advisory review process that may lead to Dependabot alerts for affected repositories. Do not interpret a release-only subscription as complete security coverage. Review the project’s published advisories and relevant dependency alerts, comparing affected versions and any fixed version with your inventory. An advisory may lack a fixed version, so the practical response can involve mitigation or further investigation rather than an immediately available upgrade.

Turn each signal into a reviewable action

Begin by recording the official repository, installed version, distribution channel, and responsible reviewer. Inspect Releases and Tags, choose the discovery channel, and compare its initial entries with GitHub. For each relevant item, open the source page, read breaking changes and migration instructions, check advisories, and confirm that the distributed package matches what you actually run. Record a decision to schedule, investigate, or defer with a reason. As a hypothetical example, a team using a stable command-line tool could route release announcements to routine review and prereleases to evaluation. That illustrates a policy, not a reported deployment result.

Audit silence as well as incoming updates

Periodically revisit the repository and distribution channel even when no feed items arrive. Check whether the project still publishes GitHub releases, whether tags reveal versions missing from your chosen channel, and whether your reader reports fetching errors. If both release and tag feeds are enabled, group matching candidates by repository and version while preserving their original links; two entries need not mean two upgrades. Keep monitoring health distinct from software status: a successful fetch only shows that the channel responded. The final outcome should be a traceable update decision, not simply an unread count reaching zero.

Primary sources and methodology

Documentation-based synthesis reviewed on 2026-11-03 using the official GitHub sources below, plus inspection of the release and tag Atom links advertised in the official GitHub CLI repository’s Releases HTML. Link inspection establishes advertised subscription addresses, not feed completeness or reader delivery. No notification latency or upgrade outcome was tested. The team workflow example is hypothetical.

• GitHub Docs: About releases
• GitHub Docs: Configuring notifications
• GitHub Docs: Managing releases in a repository
• GitHub Docs: REST API endpoints for releases
• GitHub Docs: Immutable releases
• GitHub Docs: REST API endpoints for Git references
• GitHub Docs: Repository security advisories
• Official GitHub CLI Releases page: advertised release and tag Atom links