Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
G
gitlab-runner
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Lars Seipel
gitlab-runner
Commits
4fbfae5d
Unverified
Commit
4fbfae5d
authored
8 years ago
by
Tomasz Maczukin
Browse files
Options
Downloads
Patches
Plain Diff
Add release process description
[ci skip]
parent
e62671cd
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/release_process/README.md
+137
-32
137 additions, 32 deletions
docs/release_process/README.md
with
137 additions
and
32 deletions
docs/release_process/README.md
+
137
−
32
View file @
4fbfae5d
# GitLab Runner release process
# GitLab Runner release process
To handle the growth of this project, in
`v1.
4
`
we've introduced a release process correlated
To handle the growth of this project, in
`v1.
6
`
we've introduced a release process correlated
with GitLab's CE/EE release process.
with GitLab's CE/EE release process.
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents**
-
[
Release roadmap
](
#release-roadmap
)
-
[
Stable release timeline
](
#stable-release-timeline
)
-
[
Supported releases
](
#supported-releases
)
-
[
Release planning
](
#release-planning
)
-
[
Workflow, merging and tagging strategy
](
#workflow-merging-and-tagging-strategy
)
-
[
Stable release
](
#stable-release
)
-
[
Patch releases
](
#patch-releases
)
-
[
Documentation
](
#documentation
)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Release roadmap
## Release roadmap
Starting with
`v1.4`
GitLab Runner
will be
released on the 22th day of each month - together
Starting with
`v1.4`
GitLab Runner
is
released on the 22th day of each month - together
with GitLab CE and GitLab EE projects.
with GitLab CE and GitLab EE projects.
> What to describe:
### Stable release timeline
> - release timeline
> - working on features
-
12th day of a month:
> - feature window closed - bugfixes and documentation update
-
tag first RC version on
`master`
branch
>
-
deploy the RC version to
`docker-ci-X.gitlap.com`
> > **Note:** there is nothing bad in moving a feature do the next release at this stage, if
(each next RC version should be deployed to above hosts)
> > it's still not working well!
>
-
17th day of a month:
> - release day
-
tag next RC version on
`master`
branch
> - release fixes and documentation improvements
-
deploy the current RC version to
`shared-runners-manager-X.gitlab.com`
> - _backlog_ milestone
(each next RC version should be deployed to above hosts)
> - no RC packages - constantly updated Bleeding Edge
-
20th day of a month:
## Git workflow, merging and tagging strategy
-
close the _new features_ window.
> What to describe:
From now on we're merging only features that are ready and
> - how normal workflow works
features that are _almost ready_ but are waiting for
> - when to tag
bugfixes/documentation
> - how merge patch release fixes into master (or vice versa)
> - x-y-stable branch and cherry-pick
> There is nothing bad in moving a feature to the next release at this stage,
> - pick-into-stable label
> if it's still not _production ready_!
-
21th day of a month:
-
tag last RC version
-
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`
-
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
-
announce the new release in _GitLab's release blog post_
-
start the
`pick-into-stable`
strategy for the
`X-Y-stable`
branch
### Supported releases
Because of a fast development and release cycle - we release a new version
each 22th day of a month! - we need to prepare a strict policy of releases
supporting.
With this release process description we're starting the _last three
releases support_ policy. That means when we'll release a
`v1.6`
version
we will still support
`v1.5.x`
and
`v1.4.x`
versions. But only them.
After releasing
`v1.7`
we'll support
`v1.5.x`
and
`v1.6.x`
and so on.
Each support requests for previous versions will be closed with
a ~wontfix label.
**What is supported?**
By the _release support_ we understand:
-
fixes for security bugs
-
fixes for other bugs
-
requests for documentation
-
questions of type _"How can I ...?"_ related to a supported version
Proposals of new features or improvements are welcome but will be not
prepared for supported releases. Instead - if we decide to implement
them - they will be planned for one of upcoming releases.
### Release planning
For release planning we use the
[
_milestones_
][
runner-milestones
]
feature.
Each issue or merge request planned for a release will be assigned to
one of
`vX.Y`
milestones. This rule will be very important after
releasing the version when
`pick-into-stable`
strategy will be used to
merge changes into release stable branch.
After releasing a version the
`vX.Y`
milestone will be still used to assign
issues and merge requests related to support process.
We will plan only one version ahead. However we still want to have a way
to mark issues or merge requests that we decided to include in upcoming
releases even if we don't know when we'll have time for it. For this
purpose we've prepared the %Backlog milestone.
## Workflow, merging and tagging strategy
### Stable release
-
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
-
if feature is planned for the current release (confirmed by the
assigned milestone) - merge branch into master
### Patch releases
-
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
-
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
-
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
-
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
## Documentation
## Documentation
> What to describe
:
Some documentation tips
:
> - documentation tips
> - when to c
reate documentation
1.
C
reate documentation
as late as it's possible, but before the change
> - how
to ma
rk features that need modifications in both Runner and GitLab CE/EE
is added in
to
`
ma
ster`
/
`X-Y-stable`
branch (before the MR is merged).
## Patch releases
1.
How to mark features that need modifications in both Runner and GitLab CE/EE???
> Need to describe this
> What to describe:
[
runner-milestones
]:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/milestones
> - when to prepare
> - how to release
> - how many releases backward we will support
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment