You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[chore] Update release manager rotation and include contrib and 'releases' release managers (#13385)
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Updates release doc to split into core, contrib and 'releases' release
managers.
Includes list of people.
<!-- Issue number if applicable -->
#### Link to tracking issue
Updates #13314
---------
Co-authored-by: Damien Mathieu <[email protected]>
Copy file name to clipboardExpand all lines: docs/release.md
+50-28Lines changed: 50 additions & 28 deletions
Original file line number
Diff line number
Diff line change
@@ -2,28 +2,28 @@
2
2
3
3
Collector build and testing is currently fully automated. However there are still certain operations that need to be performed manually in order to make a release.
4
4
5
-
We release both core and contrib collectors with the same versions where the contrib release uses the core release as a dependency. We’ve divided this process into four sections. A release engineer must release:
5
+
We release both core and contrib collectors with the same versions where the contrib release uses the core release as a dependency. We’ve divided this process into three sections. Each section is assigned to an approver or maintainer of the corresponding repository. The sections are:
6
6
7
7
1. The [Core](#releasing-opentelemetry-collector) collector, including the collector builder CLI tool.
8
-
2. The [Contrib](#releasing-opentelemetry-collector-contrib) collector.
8
+
2. The [Contrib](#releasing-opentelemetry-collector-contrib) collector repository, containing Collector components.
9
9
3. The [artifacts](#producing-the-artifacts)
10
10
11
11
**Important Note:** You’ll need to be able to sign git commits/tags in order to be able to release a collector version. Follow [this guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) to set it up.
12
12
13
-
## Release manager
13
+
## Release managers
14
14
15
15
A release manager is the person responsible for a specific release. While the manager might request help from other folks, they are ultimately responsible for the success of a release.
16
16
17
-
In order to have more people comfortable with the release process, and in order to decrease the burden on a small number of volunteers, all coreapprovers are release managers from time to time, listed under the [Release Schedule](#release-schedule) section. That table is updated at every release, with the current manager adding themselves to the bottom of the table, removing themselves from the top of the table.
17
+
In order to have more people comfortable with the release process, and in order to decrease the burden on a small number of volunteers, all core, contrib and releases approvers are release managers from time to time, listed under the [Release Schedule](#release-schedule) section. That table is updated at every release, with the current core release manager adding themselves to the bottom of the table, removing themselves from the top of the table.
18
18
19
-
It is possible that a core approver isn't a contrib approver. In that case, the release manager should coordinate with a contrib approver for the steps requiring this role, such as branch creation or tag publishing.
19
+
The assigned release managers should coordinate with each other to ensure a smooth release process. The release managers may be the same person for different repositories, but it is not required.
20
20
21
-
To ensure the rest of the community is informed about the release and can properly help the release manager, the release manager should open a thread on the #otel-collector-dev CNCF Slack channel and provide updates there.
22
-
The thread should be shared with all Collector leads (coreand contrib approvers and maintainers).
21
+
To ensure the rest of the community is informed about the release and can properly help the release manager, the core release manager should open a thread on the #otel-collector-dev CNCF Slack channel and provide updates there.
22
+
The thread should be shared with all Collector leads (core, contrib and releases approvers and maintainers).
23
23
24
24
Before the release, make sure there are no open release blockers in [core](https://github.com/open-telemetry/opentelemetry-collector/labels/release%3Ablocker), [contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/labels/release%3Ablocker) and [releases](https://github.com/open-telemetry/opentelemetry-collector-releases/labels/release%3Ablocker) repos.
1. Update Contrib to use the latest in development version of Core by running [Update contrib to the latest core source](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/update-otel.yaml). This is to ensure that the latest core does not break contrib in any way. If the job is failing for any reason, you can do it locally by running `make update-otel` in Contrib root directory and pushing a PR. If you are unable to run `make update-otel`, it is possible to skip this step and resolve conflicts with Contrib after Core is released, but this is generally inadvisable.
29
29
- While this PR is open, all merging in Core is automatically halted via the `Merge freeze / Check` CI check.
@@ -65,7 +65,7 @@ Before the release, make sure there are no open release blockers in [core](https
65
65
66
66
7. A new `v0.85.0` source code release should be automatically created on Github by now. Its description should already contain the corresponding CHANGELOG.md and CHANGELOG-API.md contents.
1. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/prepare-release.yml). When prompted, enter the version numbers of the current and new beta versions, but do not include a leading `v`. This action will create a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Contrib should be halted**.
71
71
- If the PR needs updated in any way you can make the changes in a fork and PR those changes into the `prepare-release-prs/x` branch. You do not need to wait for the CI to pass in this prep-to-prep PR.
@@ -91,9 +91,9 @@ Before the release, make sure there are no open release blockers in [core](https
91
91
92
92
5. Manually edit the release description, and add a section listing the unmaintained components at the top ([example](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.114.0)). The list of unmaintained components can be found by [searching for issues with the "unmaintained" label](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aissue%20state%3Aopen%20label%3Aunmaintained).
93
93
94
-
## Producing the artifacts
94
+
## Producing the artifacts ('releases' release manager)
95
95
96
-
The last step of the release process creates artifacts for the new version of the collector and publishes images to Dockerhub. The steps in this portion of the release are done in the [opentelemetry-collector-releases](https://github.com/open-telemetry/opentelemetry-collector-releases) repo.
96
+
The last step of the release process creates artifacts for the new version of the Collector and publishes images to Dockerhub. The steps in this portion of the release are done in the [opentelemetry-collector-releases](https://github.com/open-telemetry/opentelemetry-collector-releases) repo.
97
97
98
98
1. Run the GitHub Action workflow "[Update Version in Distributions and Prepare PR](https://github.com/open-telemetry/opentelemetry-collector-releases/actions/workflows/update-version.yaml)" which will update the minor version automatically (e.g. v0.116.0 -> v0.117.0) or manually provide a new version if releasing a bugfix or skipping a version. Select "create pr" option.
99
99
- 🛑 **Do not move forward until this PR is merged.** 🛑
@@ -124,15 +124,18 @@ The last step of the release process creates artifacts for the new version of th
124
124
125
125
6. Update the release notes with the CHANGELOG.md updates.
126
126
127
-
## Post-release steps
127
+
## Post-release steps (all release managers)
128
128
129
129
After the release is complete, the release manager should do the following steps:
130
130
131
131
1. Create an issue or update existing issues for each problem encountered throughout the release in
132
132
the appropriate repositories and label them with the `release:retro` label. The release manager
133
133
should share the list of issues that affected the release with the Collector leads.
134
134
2. Update the [release schedule](#release-schedule) section of this document to remove the completed
135
-
releases and add new schedules to the bottom of the list.
135
+
releases and add new schedules to the bottom of the list. To update the release schedule, follow these rules:
136
+
1. If the core release manager is also eligible as a contrib and 'releases' release manager, assign them to all roles they can perform.
137
+
2. Otherwise, pick a contrib/'releases' approver/maintainer that is not a core approver/maintainer, rotating through the list of eligible people. The contrib approvers/maintainers are all members of the [@collector-contrib-approvers](https://github.com/orgs/open-telemetry/teams/collector-contrib-approvers) team, and the 'releases' approvers/maintainers are all members of the [@collector-releases-approvers](https://github.com/orgs/open-telemetry/teams/collector-releases-approvers) team.
138
+
136
139
137
140
## Troubleshooting
138
141
@@ -178,7 +181,7 @@ releases and add new schedules to the bottom of the list.
178
181
179
182
### Bugfix release criteria
180
183
181
-
Both `opentelemetry-collector` and `opentelemetry-collector-contrib` have very short 2 week release cycles. Because of this, we put a high bar when considering making a patch release, to avoid wasting engineering time unnecessarily.
184
+
All OpenTelemetry Collector repositories have very short 2 week release cycles. Because of this, we put a high bar when considering making a patch release, to avoid wasting engineering time unnecessarily.
182
185
183
186
When considering making a bugfix release on the `v0.N.x` release cycle, the bug in question needs to fulfill the following criteria:
184
187
@@ -202,7 +205,7 @@ If the maintainers are unable to reach consensus within one working day, we will
202
205
203
206
### Bugfix release procedure
204
207
205
-
The release manager of a minor version is responsible for releasing any bugfix versions on this release series. The following documents the procedure to release a bugfix
208
+
The release manager of a minor version is responsible for releasing any bugfix versions on this release series for their repository. The following documents the procedure to release a bugfix:
206
209
207
210
1. Create a pull request against the `release/<release-series>` (e.g. `release/v0.90.x`) branch to apply the fix.
208
211
2. Make sure you are on `release/<release-series>`. Prepare release commits with `prepare-release` make target, e.g. `make prepare-release PREVIOUS_VERSION=0.90.0 RELEASE_CANDIDATE=0.90.1 MODSET=beta`, and create a pull request against the `release/<release-series>` branch.
@@ -227,16 +230,35 @@ Once a module is ready to be released under the `1.x` version scheme, file a PR
0 commit comments