* otel to 1.24 * prometheus exporter to 0.46 * bunotel to 1.1.17 Also: * Use schemaless URL for metrics * Add software version to tracing schema
5.6 KiB
Release Process
Semantic Convention Generation
New versions of the OpenTelemetry Semantic Conventions mean new versions of the semconv
package need to be generated.
The semconv-generate
make target is used for this.
- Checkout a local copy of the OpenTelemetry Semantic Conventions to the desired release tag.
- Pull the latest
otel/semconvgen
image:docker pull otel/semconvgen:latest
- Run the
make semconv-generate ...
target from this repository.
For example,
export TAG="v1.21.0" # Change to the release version you are generating.
export OTEL_SEMCONV_REPO="/absolute/path/to/opentelemetry/semantic-conventions"
docker pull otel/semconvgen:latest
make semconv-generate # Uses the exported TAG and OTEL_SEMCONV_REPO.
This should create a new sub-package of semconv
.
Ensure things look correct before submitting a pull request to include the addition.
Breaking changes validation
You can run make gorelease
that runs gorelease to ensure that there are no unwanted changes done in the public API.
You can check/report problems with gorelease
here.
Pre-Release
First, decide which module sets will be released and update their versions
in versions.yaml
. Commit this change to a new branch.
Update go.mod for submodules to depend on the new release which will happen in the next step.
-
Run the
prerelease
make target. It creates a branchprerelease_<module set>_<new tag>
that will contain all release changes.make prerelease MODSET=<module set>
-
Verify the changes.
git diff ...prerelease_<module set>_<new tag>
This should have changed the version for all modules to be
<new tag>
. If these changes look correct, merge them into your pre-release branch:git merge prerelease_<module set>_<new tag>
-
Update the Changelog.
-
Make sure all relevant changes for this release are included and are in language that non-contributors to the project can understand. To verify this, you can look directly at the commits since the
<last tag>
.git --no-pager log --pretty=oneline "<last tag>..HEAD"
-
Move all the
Unreleased
changes into a new section following the title scheme ([<new tag>] - <date of release>
). -
Update all the appropriate links at the bottom.
-
-
Push the changes to upstream and create a Pull Request on GitHub. Be sure to include the curated changes from the Changelog in the description.
Tag
Once the Pull Request with all the version changes has been approved and merged it is time to tag the merged commit.
IMPORTANT: It is critical you use the same tag that you used in the Pre-Release step!
Failure to do so will leave things in a broken state. As long as you do not
change versions.yaml
between pre-release and this step, things should be fine.
IMPORTANT: There is currently no way to remove an incorrectly tagged version of a Go module. It is critical you make sure the version you push upstream is correct. Failure to do so will lead to minor emergencies and tough to work around.
-
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.make add-tags MODSET=<module set> COMMIT=<commit hash>
It should only be necessary to provide an explicit
COMMIT
value if the currentHEAD
of your working directory is not the correct commit. -
Push tags to the upstream remote (not your fork:
github.com/open-telemetry/opentelemetry-go.git
). Make sure you push all sub-modules as well.git push upstream <new tag> git push upstream <submodules-path/new tag> ...
Release
Finally create a Release for the new <new tag>
on GitHub.
The release body should include all the release notes from the Changelog for this release.
Verify Examples
After releasing verify that examples build outside of the repository.
./verify_examples.sh
The script copies examples into a different directory removes any replace
declarations in go.mod
and builds them.
This ensures they build with the published release, not the local copy.
Post-Release
Contrib Repository
Once verified be sure to make a release for the contrib
repository that uses this release.
Website Documentation
Update the Go instrumentation documentation in the OpenTelemetry website under content/en/docs/languages/go. Importantly, bump any package versions referenced to be the latest one you just released and ensure all code examples still compile and are accurate.
Demo Repository
Bump the dependencies in the following Go services: