Skip to content

Latest commit

 

History

History
80 lines (61 loc) · 5.03 KB

9-version-control.md

File metadata and controls

80 lines (61 loc) · 5.03 KB
Raw

Version Control

We use Git to manage our code and use GitFlow as our workflow. Whenever possible, simply create a branch on the project repo rather than forking to another repository. This is because there are some workflows that only run on the main repository (such as build steps and cypress cloud test submission). For testing it is important to have these workflows and artifacts in place. If you do not have proper permission to create a branch on the repository in question, please request access.

Branch Naming

For each branch type defined by GitFlow, the following branch naming patterns are acceptable:

Branch Type Pattern
main main (preferred)
master
trunk
hotfix hotfix/* - where * represents the semantic version number (e.g. hotfix/1.2.1)
release release/* - where * represents the semantic version number (e.g release/1.2.0)
develop develop
feature feature/* - new feature
add/* - new feature
update/* - improve an existing feature
fix/* - non-urgent bugfixes
try/* - experiments

The asterisks can be replaced with a descriptive name, or a ticket number.

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 an 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

  • An alpha release is open to adding new features
  • A beta release is open to adding bugfixes
  • A release candidate is a stable release that is not ready for production

Code Review & Release Restrictions

  • All teams will handle code reviews and releases internally for any repositories they are responsible for.
  • All teams can request a code review from the WordPress COE team at any time.
  • All teams are expected to request an architectural review from the WordPress COE team in the early stages of any new development.
  • All code merged into the develop branch of any repository must be done as a pull request which is to be reviewed by at least one other member from the same team.
  • All releases on the main branch for brand plugins must be handled by the WordPress COE team.
  • All releases on the main branch for modules must be handled by the team that owns the module.
  • All pre-releases on the develop, release/*, or hotfix/* branches can be done by anyone on any repository as long as the proper conventions are followed.
  • Tests should be written for all new code, or updated for existing code, by the team developing the functionality or making the change.
  • No pull requests are to be merged until it has:
    • At least one code review
    • All tests pass
    • Linting passes
    • Tests are written for any new features or code changes

GitHub Actions

Stage Trigger Actions
Feature On push to a feature branch Run linting and tests. Run a build (plugins & themes only)
Develop On push or PR to the develop branch
On alpha or beta release		 Run linting and tests. Run a build (plugins & themes only)
Run linting and the full test matrix. Run a build (plugins & themes only)
Release On push or PR to a release branch
On a release candidate release		 Run linting and tests. Run a build (plugins & themes only)
Run linting and the full test matrix. Run a build (plugins & themes only)
Hotfix On push or PR to a hotfix branch
On a release candidate release		 Run linting and tests. Run a build (plugins & themes only)
Run linting and the full test matrix. Run a build (plugins & themes only)
Main On push to the main branch Run linting and full test matrix. Run a build (plugins & themes only)