git-flow is used to manage releases.
- Release branch exists as
release/X.Y.Z
in GitHub repository. - Release tag exists as
X.Y.Z
in GitHub repository. - The
HEAD
of themain
branch hasX.Y.Z
tag. - The hash of the
HEAD
of themain
branch exists in thedevelop
branch. This is to ensure that everything pushed tomain
exists indevelop
(in case ifmain
had any hot-fixes that not yet have been merged todevelop
). - There are no PRs in GitHub related to the release.
Release versions are numbered according to Semantic Versioning.
Given a version number X.Y.Z
:
X
= Major release version. No leading zeroes.Y
= Minor Release version. No leading zeroes.Z
= Hotfix/patch version. No leading zeroes.
Examples:
- Correct:
0.1.0
,1.0.0
,1.0.1
,1.0.10
- Incorrect:
0.1
,1
,1.0
,1.0.01
,1.0.010
This repository is a mono-repository, meaning that it contains multiple packages
that are published to other repositories on every commit to develop
branch.
Releasing to this repository will not create releases in other repositories. This was done purposefully to avoid creating releases in other repositories when there are no changes in them and to allow having own versions in published repositories as changes in this repository do not necessarily mean that there are changes in published repositories.
Release log of this repository must contain all the changes that were made to all the packages that are published from this repository. Parts of the release log can then be manually copied to the release logs of published repositories.
Releases to Drupal.org are done manually.
Every commit merged to the develop
is pushed to Drupal.org to the 1.x-dev
branch, meaning that every commit may be used in a new release. This was done
on purpose to avoid accidental releases done in GitHub (it is not possible to
delete releases in Drupal.org).
The tags from this repository are not pushed to Drupal.org.
When a release is published as a tag in GitHub, the release version must be manually created in Drupal.org.