Releases and versioning

Release cadence, semantic versioning, and the tags each branch type may carry

Id general-releases Applies to any Status active Enforceable yes, no check yet Tags releasessemvertagging

This document covers what versions mean and how they are tagged. The step by step of actually running a release is the release runbook.

Cadence

Releases and pre-releases

All production releases for brand plugins should be tagged by the WordPress COE team. Module releases and brand plugin pre-releases can be tagged by anyone, but MUST be marked on GitHub as a pre-release.

Failure to properly name and mark a release as a pre-release can result in the release being automatically deployed to production.

Tagging

Release version tags should adhere to semantic versioning and only be tagged on the applicable branches:

Tag Branch Examples
X.Y.Z main, master, trunk 1.2.0
X.Y.Z-rc.N hotfix/1.2.1 1.2.1-rc.1, 1.2.1-rc.2
X.Y.Z-rc.N release/1.2.0 1.2.0-rc.1, 1.2.0-rc.2
X.Y.Z-alpha.N develop 1.2.2-alpha.1, 1.2.2-alpha.2
X.Y.Z-beta.N develop 1.2.2-beta.1, 1.2.2-beta.2

Capital letters represent the numbers that are changeable. Lowercase letters represent the numbers that are fixed.

X = major version number
Y = minor version number
Z = patch version number
N = release candidate, alpha, or beta number

Notes on versioning