|
| 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