Commit 6743d6c9 authored by Nick Thomas's avatar Nick Thomas

Merge branch 'process-patch-releases' into 'master'

Update versioning process

See merge request gitlab-org/gitlab-workhorse!334
parents 13e87259 55a263a8
...@@ -21,5 +21,28 @@ maintainers. The release process is: ...@@ -21,5 +21,28 @@ maintainers. The release process is:
- create a merge request to update CHANGELOG and VERSION on the - create a merge request to update CHANGELOG and VERSION on the
respective release branch (usually `master`) respective release branch (usually `master`)
- make sure the new version number adheres to our [versioning standard](#versioning)
- merge the merge request - merge the merge request
- run `make release` on the release branch - run `make release` on the release branch
## Versioning
Workhorse uses a variation of SemVer. We don't use "normal" SemVer
because we have to be able to integrate into GitLab stable branches.
A version has the format MAJOR.MINOR.PATCH.
- Major and minor releases are tagged on the `master` branch
- If the change is backwards compatible, increment the MINOR counter
- If the change breaks compatibility, increment MAJOR and set MINOR to `0`
- Patch release tags must be made on stable branches
- Only make a patch release when targeting a GitLab stable branch
This means that tags that end in `.0` (e.g. `8.5.0`) must always be on
the master branch, and tags that end in anthing other than `.0` (e.g.
`8.5.2`) must always be on a stable branch.
> The reason we do this is that SemVer suggests something like a
> refactoring constitutes a "patch release", while the GitLab stable
> branch quality standards do not allow for back-porting refactorings
> into a stable branch.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment