3.2 KiB

Raw Blame History

Versioning and releasing

OpenTelemetry Auto-Instrumentation for Java uses SemVer standard for versioning of its artifacts.

The version is specified in version.gradle.kts.

Snapshot builds

Every successful CI build of the main branch automatically executes ./gradlew publishToSonatype as the last step, which publishes a snapshot build to Sonatype OSS snapshots repository.

Starting the Release

Before making the release:

Merge a PR to main updating the CHANGELOG.md
- Use the script at buildscripts/draft-change-log-entries.sh to help create an initial draft. We typically only include end-user facing changes in the change log.
Run the Prepare Release Branch workflow.
Review and merge the two PRs that it creates (one is targeted to the release branch and one is targeted to the main branch)
Delete the branches from these two PRs since they are created in the main repo

Open the Release workflow.

Press the "Run workflow" button, then select the release branch from the dropdown list, e.g. v1.9.x, and click the "Run workflow" button below that.

This triggers the release process, which builds the artifacts, publishes the artifacts, and creates and pushes a git tag with the version number.

After making the release:

Merge a PR to main with the following change
- Bump the version in the download link in the root README.md file

Announcement

Once the GitHub workflow completes, go to Github release page, find the draft release created by the release workflow, and copy the change log into it.

Patch Release

All patch releases should include only bug-fixes, and must avoid adding/modifying the public APIs.

In general, patch releases are only made for bug-fixes for the following types of issues:

Regressions
Memory leaks
Deadlocks