* Add semantic convention generator Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Update semantic conventions from generator Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Use existing internal/tools module Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Fix lint issues, more initialisms Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Update changelog Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * semconvgen: Faas->FaaS Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Fix a few more key names with replacements * Update replacements from PR feedback Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * rename commonInitialisms to capitalizations, move some capitalizations there Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Regenerate semantic conventions with updated capitalizations and replacements Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Generate semantic conventions from spec v1.3.0 Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Cleanup semconv generator util a bit Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * No need to put internal tooling additions in the CHANGELOG Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Fix HTTP semconv tests Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Add semconv generation notes to RELEASING.md Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
4.2 KiB
Release Process
Semantic Convention Generation
If a new version of the OpenTelemetry Specification has been released it will be necessary to generate a new
semantic convention package from the YAML definitions in the specification repository. There is a utility in
internal/tools/semconv-gen
that can be used to generate the semconv
package. This will ideally be done
shortly after the specification release is tagged, but it is also good practice to ensure that current conventions
are current before creating a release tag.
There are currently two categories of semantic conventions that must be generated, resource
and trace
.
cd internal/tools/semconv-gen
go run generate.go -i /path/to/specification/repo/semantic_conventions/resource
go run generate.go -i /path/to/specification/repo/semantic_conventions/trace
Using default values for all options other than input
will result in using the template.j2
template to
generate resource.go
and trace.go
in /path/to/otelgo/repo/semconv
.
Pre-Release
Update go.mod for submodules to depend on the new release which will happen in the next step.
-
Run the pre-release script. It creates a branch
pre_release_<new tag>
that will contain all release changes../pre_release.sh -t <new tag>
-
Verify the changes.
git diff main
This should have changed the version for all modules to be
<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.
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.
-
Run the tag.sh script using the
<commit-hash>
of the commit on the main branch for the merged Pull Request../tag.sh <new tag> <commit-hash>
-
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.
Additionally, the tag.sh
script generates commit logs since last release which can be used to supplement the release notes.
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 documentation for the OpenTelemetry website. Importantly, bump any package versions referenced to be the latest one you just released and ensure all code examples still compile and are accurate.