Skip to content

Commit b76693b

Browse files
committed
Add releasing documentation
Document how maintainers perform releases.
1 parent 6fc7f27 commit b76693b

File tree

1 file changed

+90
-0
lines changed

1 file changed

+90
-0
lines changed

RELEASING.md

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
1+
# Release Process
2+
3+
## Pre-Release
4+
5+
First, decide which module sets will be released and update their versions in `versions.yaml`.
6+
Commit this change to a new branch (i.e. `release-vX.X.X`).
7+
8+
Update all crosslink dependencies and any version references in code.
9+
10+
1. Run the `prerelease` make target.
11+
12+
```console
13+
make prerelease MODSET=<module set>
14+
```
15+
16+
For example, to prepare a release for the `obi` module set, run:
17+
18+
```console
19+
make prerelease MODSET=obi
20+
```
21+
22+
This will create a branch `prerelease_<module set>_<new tag>` that will contain all release changes.
23+
24+
2. Verify the changes.
25+
26+
```console
27+
git diff ...prerelease_<module set>_<new tag>
28+
```
29+
30+
This should have changed the version for all modules to be `<new tag>`, if there are any crosslink dependencies.
31+
32+
If these changes look correct, merge them into your pre-release branch:
33+
34+
```console
35+
git merge prerelease_<module set>_<new tag>
36+
```
37+
38+
3. Push the changes to upstream and create a Pull Request on GitHub.
39+
Be sure to include the curated changes from the [Changelog](./CHANGELOG.md) in the description.
40+
41+
## Tag
42+
43+
Once the Pull Request with all the version changes has been approved and merged it is time to tag the merged commit.
44+
45+
<!-- markdownlint-disable MD028 -->
46+
> [!CAUTION]
47+
> It is critical you use the same tag that you used in the Pre-Release step!
48+
> Failure to do so will leave things in a broken state.
49+
> As long as you do not change `versions.yaml` between pre-release and this step, things should be fine.
50+
51+
> [!CAUTION]
52+
> [There is currently no way to remove an incorrectly tagged version of a Go module](https://github.com/golang/go/issues/34189).
53+
> It is critical you make sure the version you push upstream is correct.
54+
> [Failure to do so will lead to minor emergencies and tough to work around](https://github.com/open-telemetry/opentelemetry-go/issues/331).
55+
<!-- markdownlint-enable MD028 -->
56+
57+
1. For each module set that will be released, run the `add-tags` make target using the `<commit-hash>` of the commit on the main branch for the merged Pull Request.
58+
59+
```console
60+
make add-tags MODSET=<module set> COMMIT=<commit hash>
61+
```
62+
63+
For example, to add tags for the `obi` module set for the latest commit, run:
64+
65+
```console
66+
make add-tags MODSET=obi
67+
```
68+
69+
It should only be necessary to provide an explicit `COMMIT` value if the
70+
current `HEAD` of your working directory is not the correct commit.
71+
72+
2. Push tags to the upstream remote (not your fork: `github.com/open-telemetry/opentelemetry-go.git`).
73+
Make sure you push all sub-modules as well.
74+
75+
```console
76+
git push upstream <new tag>
77+
git push upstream <submodules-path/new tag>
78+
...
79+
```
80+
81+
## Release
82+
83+
Finally create a Release for the new `<new tag>` on GitHub.
84+
85+
Currently we do not have a curated changelog.
86+
Use the Github automated changelog generation to create the release notes.
87+
88+
## Post-Release
89+
90+
**TODO**: bump versions in Helm charts and other places.

0 commit comments

Comments
 (0)