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:

Close the release milestone if there is one
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.
- Specify the (estimated) release date (UTC)
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.

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
Use the script at .github/scripts/generate-release-contributors.sh to generate the list of release contributors
Select the checkbox for "Create a discussion for this release"
Press the "Publish release" button

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

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