Commit 84aa9704 authored by Tomasz Maczukin's avatar Tomasz Maczukin

Merge branch 'update-runner-release-docs' into 'master'

Update runner release docs

See merge request gitlab-org/gitlab-runner!1070
parents d31a4dc0 da0f17c6
......@@ -14,43 +14,9 @@ together with GitLab CE and GitLab EE projects.
### Stable release timeline
- 12th day of a month:
- tag first RC version on `master` branch, e.g., `v1.6.0-rc1`
- deploy the RC version to `docker-ci-X.gitlap.com`
(each next RC version until the next date should be deployed to those hosts)
- 17th day of a month:
- tag next RC version on `master` branch, e.g., `v1.6.0-rc2`
- deploy the current RC version to `shared-runners-manager-X.gitlab.com`
(each next RC version until the next date should be deployed to those hosts)
- 20th day of a month:
- close the _new features_ window.
From now on we're merging only features that are ready and are eventually
waiting for documentation or last fixes. After the _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_!
- 21th day of a month:
- tag last RC version, e.g., `v1.6.0-rc5`
- 22nd day of a month:
- 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
- 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 for the next release
- all MRs that are meant to go into the upcoming release should have the
correct milestone assigned _and_ the `Pick into X.Y` label where `X.Y` is
equal to the milestone, so that release managers can find and pick them.
Merge requests without this label will not be merged into the stable branch.
For a detailed timeline on how `gitlab-runner` is released and deployed, you
can follow the [release check
list](https://gitlab.com/gitlab-org/gitlab-runner/blob/master/.gitlab/issue_templates/Release%20Checklist.md).
### Supported releases
......
......@@ -116,5 +116,5 @@ are required to release the Runner.
the CI/CD Pipeline for tag will pass. If the latest Pipeline for `master` was passing
then following the process above there should be not changes that could fail the pipeline
at this time. Any failures should be a temoprary failures related to CI infrastructure
and GitLab stability. In that case just retry te failing job.
and GitLab stability. In that case just retry the failing job.
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