There are two types of release for the go.opentelemetry.io/contrib
repo
and submodules.
-
Case 1 A release due to changes independent of the
go.opentelemetry.io/otel
module, e.g. perhaps a critical bug fix in one of the contrib modules. -
Case 2 A release due to a breaking API change in
go.opentelemetry.io/otel
which all modules in this repo depend on.
Update go.mod for submodules to depend on the upcoming new release of
the module in this repo, go.opentelemetry.io/contrib
. Decide on the
next version of the semantic tag to apply to the contrib
module based on whether you fall into Case 1 or Case 2.
If the changes are all internal to this repo, then the new tag will
most often be a patch or minor version upgrade to the existing tag on
this module. Let's call this <new_contrib_tag>
.
If a new release is required due to breaking changes in
go.opentelemetry.io/otel
, then the new semantic tag for this repo
should be bumped to match the go.opentelemetry.io/otel
new tag.
Let's call this <new_otel_tag>
. The script checks that
go.opentelemetry.io/otel@v<new_otel_tag>
is a valid tag, so you need
to wait until that tag has been pushed in the main repo.
In nearly all cases, <new_contrib_tag>
should be the same as
<new_otel_tag>
.
-
Run
pre_release.sh
script to create a branchpre_release_<new_contrib_tag>
. The script will also rungo mod tidy
andmake ci
.- Case 1
./pre_release.sh -t <new_contrib_tag>
- Case 2
./pre_release.sh -o <new_otel_tag> [-t <new_contrib_tag>]
- Case 1
-
If you used
-o <new_otel_tag>
to rewrite the modules to depend on a new version ofgo.opentelemetry.io/otel
, there will likely be breaking changes that require fixes to the files in thiscontrib
repo. Make the appropriate fixes to address any API breaks and run through the``` git commit -m "fixes due to API changes" make precommit ```
cycle until everything passes
-
Push the changes to upstream.
git diff master git push
-
Create a PR on github and merge the PR once approved.
Now create a <new_contrib_tag>
on the commit hash of the changes made in pre-release step,
-
Run the tag.sh script.
./tag.sh <new_contrib_tag> <commit-hash>
-
Push tags upstream. Make sure you push upstream for all the sub-module tags as well.
git push upstream <new_contrib_tag> git push upstream <submodules-path/new_contrib_tag> ...
Now create a release for the new <new_contrib_tag>
on github.
The release body should include all the release notes in the Changelog for this release.
Additionally, the tag.sh
script generates commit logs since last release which can be used to suppliment the release notes.