Skip to content

RELEASING.md

Latest commit

 

History

History
15 lines (10 loc) · 1.38 KB

RELEASING.md

File metadata and controls

15 lines (10 loc) · 1.38 KB

Semantic Release Guide

This repository uses automated semantic-release to handle version bumping, GitHub Release creation, and CHANGELOG.md generation.

How it Works

When a Pull Request is merged into the main branch, the semantic-release GitHub Action bot reads the git commit history and calculates the next version number automatically based strictly on the Conventional Commits specification.

Here is how you should prefix your PR merge commits to control the versions:

  • feat: ... ➔ Minor Release (e.g., v1.2.0 → v1.3.0). Use this when adding a new feature or command.
  • fix: ... ➔ Patch Release (e.g., v1.2.0 → v1.2.1). Use this when fixing a bug or resolving an error.
  • feat!: ... or including BREAKING CHANGE: in the footer ➔ Major Release (e.g., v1.2.0 → v2.0.0). Use this when making backwards-incompatible structural or configuration changes.
  • chore:, docs:, refactor:, test:, build:, ci: ➔ No Release. Use these for internal maintenance tasks that shouldn't trigger a new plugin release for end users.

Once a tagged commit is detected (like feat:), the bot will autonomously update the README.md version badges, generate a beautiful release Changelog, cut the Git Tag natively, and securely publish everything to GitHub using the Action's $GITHUB_TOKEN.