Skip to content
Snippets Groups Projects
Unverified Commit df17b7d3 authored by Tomasz Maczukin's avatar Tomasz Maczukin
Browse files

Update release process description 

[ci skip]
parent 4fbfae5d
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
docs/release_process/README.md
+ 91
− 26
View file @ df17b7d3
......@@ -14,6 +14,7 @@ with GitLab's CE/EE release process.
- [Workflow, merging and tagging strategy](#workflow-merging-and-tagging-strategy)
- [Stable release](#stable-release)
- [Patch releases](#patch-releases)
- [Branch naming](#branch-naming)
- [Documentation](#documentation)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
......@@ -26,36 +27,38 @@ with GitLab CE and GitLab EE projects.
### Stable release timeline
- 12th day of a month:
- tag first RC version on `master` branch
- tag first RC version on `master` branch, eg. `v1.6.0-rc.1`
- deploy the RC version to `docker-ci-X.gitlap.com`
(each next RC version should be deployed to above hosts)
- 17th day of a month:
- tag next RC version on `master` branch
- tag next RC version on `master` branch, eg. `v1.6.0-rc.2`
- deploy the current RC version to `shared-runners-manager-X.gitlab.com`
(each next RC version should be deployed to above hosts)
- 20th day of a month:
- close the _new features_ window.
From now on we're merging only features that are ready and
features that are _almost ready_ but are waiting for
bugfixes/documentation
From now on we're merging only features that are ready and are eventually
waiting for documentation or last fixes. But until _new features_ window
is closed we will not merge any feature that wasn't discussed even if it
contains all needed changes (code, new tests, documentation) and for which
all tests are passing.
> There is nothing bad in moving a feature to the next release at this stage,
> if it's still not _production ready_!
> There is nothing bad in moving a feature to the next release at this stage,
> if it's still not _production ready_!
- 21th day of a month:
- tag last RC version
- tag last RC version, eg. 'v1.6.0-rc.5'
- 22th day of a month:
- tag a stable version on `master` branch
- deploy stable version to `docker-ci-X.gitlap.com` and `shared-runners-manager-X.gitlab.com`
- update the `CHANGELOG` file with entries for current release
- tag a stable version **on `master` branch**
- create the `X-Y-stable` on the current master
- increase version number in `VERSION` file
- add a new entry to the `CHANGELOG` file
- open the _new features_ window
- deploy stable version to `docker-ci-X.gitlap.com` and `shared-runners-manager-X.gitlab.com`
- announce the new release in _GitLab's release blog post_
- open the _new features_ window
- start the `pick-into-stable` strategy for the `X-Y-stable` branch
### Supported releases
......@@ -106,36 +109,71 @@ purpose we've prepared the %Backlog milestone.
### Stable release
For a particular change:
- start work from `master` branch and open a MR into `master` branch
- assign the MR to a milestone related to the currently upcoming release
- add the `CHANGELOG` entry to a related version
- choose a good, descriptive title for the MR since it will be automatically
inserted in the `CHANGELOG` before doing the release
- if feature is planned for the current release (confirmed by the
assigned milestone) - merge branch into master
For a whole release please follow the [Stable release timeline](#stable-release-timeline).
### Patch releases
For a particular change:
- if bug exists in the currently upcoming version:
- start work from `master` branch and open a MR into `master` branch
- assign the MR to a milestone related to the oldest version in which the bug exists
- choose a good, descriptive title for the MR since it will be automatically
inserted in the `CHANGELOG` before doing the release
- assign the `pick-into-stable` label
- continue to work like with the _Stable release_
- after branch is merged - cherry-pick the merge commit to each
- merge branch into `master` branch
- after branch is merged into `master` branch - cherry-pick the merge commit to each
`X-Y-stable` branch starting from the branch related to the assigned
milestone up to the latest release
- if bug doesn't exist in the currently upcoming version:
- start work from `X-Y-stable` of the most recent version where the
bug exists and open a MR into this branch
- assign the MR to a milestone related to the oldest version in which the bug exists
- choose a good, descriptive title for the MR since it will be automatically
inserted in the `CHANGELOG` before doing the release
- assign the `pick-into-stable` label
- continue to work like with the _Stable release_
- after branch is merged - cherry-pick the merge commit to each
`X-Y-stable` branch starting from the branch related to the assigned
milestone up to the latest release before the MR target
- while cherry-picking add the `CHANGELOG` entry to each patch version
- for each `X-Y-stable` branch - if the release should be published -
create the `vX.Y.patch` tag
- add created patch versions `CHANGELOG` entries into `CHANGELOG` file
on the `master` branch
- merge branch into assigned `X-Y-stable` branch
- after branch is merged into assigned `X-Y-stable` branch - cherry-pick the merge
commit to each `X-Y-stable` branch starting from the branch related to the
assigned milestone up to the latest release before the MR target
For each `X-Y-stable` branch - if the release should be published:
- update the `CHANGELOG` file with entries for current release
- create the `vX.Y.patch` tag on the `X-Y-stable` branch
- add created `CHANGELOG` entries into `CHANGELOG` file on the `master` branch
### Branch naming
However we don't want to force any strict branch naming strategy, it would
be good if you will follow these advices:
1. Choose descriptive names for branches.
For example don't name the branch `patch-1` or `test1` (which tells nothing about its
content nor its purpose) when it could be named `remove-unused-method-from-docker-executor`.
1. Use name prefixes:
- if the branch adds/updates documentation - start its name with `docs/`,
- if the branch adds a new feature - start its name with `feature/`,
- if the branch adds a new improvement - start its name with `improvement/`,
- if the branch fixes a bug - start its name with `fix/` or `bugfix/`.
1. Including issues number in branch name is neither recommended nor discouraged.
However if you want to link the changes with an issue it's better to
create the MR from this branch as soon as possible (you can use the `WIP:` prefix
in the title to prevent from unexpected merges) and link all relevant issues
in its description.
Use `Fixes #123, #456` or `Closes #123, #345` or mix of them if it's reasonable.
Thanks to this the issue will be closed along with merging the MR.
## Documentation
......@@ -144,7 +182,34 @@ Some documentation tips:
1. Create documentation as late as it's possible, but before the change
is added into `master`/`X-Y-stable` branch (before the MR is merged).
1. How to mark features that need modifications in both Runner and GitLab CE/EE???
> Need to describe this
1. Properly mark features that need modifications in both Runner and GitLab CE/EE.
When we introduce new features we mostly mark them in the documentation
with something like:
> Notice: The feature was introduced in GitLab Runner v1.6.0`
Most of the times it's enough but sometimes we introduce a change that
needs to be released in both GitLab Runner and GitLab CE/EE to work,
eg. support for artifacts expiration.
In such case it should be properly marked in documentation, so it'll
be clear for all **what is required** for the feature to work.
We can mark it like:
> Notice: The feature was introduced in GitLab Runner v1.6.0 but it
> needs at least GitLab CE/EE 8.12 to work.
On GitLab CE/EE side (eg. in API documentation) we would then mark it like:
> Notice: The endpoint was introduced in GitLab CE/EE 8.12 but it needs
> at least GitLab Runner v1.6.0 to work.
If the changes are not released at the same time it would be good to
mark which version is not released yet:
> Notice: The endpoint was introduced in GitLab CE/EE 8.12 but it will
> need at least GitLab Runner v1.7.0 (not released yet) to work.
[runner-milestones]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/milestones
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment