Releasing Craft Plugins

A plugin release involves three independent systems that all claim to describe the same version: git tags, Packagist, and GitHub release objects. They drift from each other silently, and every observable signal can say "success" while consumers get nothing. This skill is the checklist and risk model for keeping them in agreement.

Core rule: verify what each system actually serves, not what you pushed to it. A 202 Accepted from the Packagist webhook, a green tag push, and a rendered releases page each prove nothing about the other two.

Companion Skills

• craft-php-guidelines — references/tooling.md for commit conventions and composer hygiene of the plugin manifest itself.
• craftcms — references/quality.md for the CI workflows a release depends on (code-analysis, create-release.yml).
• craft-pest — the suite must be green from the plugin's own root before tagging.

The release commit

If the plugin's composer.json carries a version key, bumping it is a mandatory release step, in the same commit that dates the changelog. A tag whose composer.json says a different version is silently useless: Packagist reads the manifest from the tag's own tree, sees the mismatch, and skips the tag —