Skip to content

RELEASING.md

Latest commit

 

History

History
71 lines (55 loc) · 4.23 KB

RELEASING.md

File metadata and controls

71 lines (55 loc) · 4.23 KB

Versioning and releasing

OpenTelemetry Java Contrib 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 the Sonatype snapshot repository.

Release cadence

This repository roughly targets monthly minor releases from the main branch on the Friday after the second Monday of the month (roughly a couple of days after the monthly minor release of opentelemetry-java-instrumentation).

Preparing a new major or minor release

  • Check that renovate has run sometime in the past day and that all renovate PRs have been merged.
    • Check that the OpenTelemetry SDK and Instrumentation versions have been updated to the latest release.
  • Close the release milestone if there is one.
  • Merge a pull request to main updating the CHANGELOG.md.
    • The heading for the unreleased entries should be ## Unreleased.
    • Use .github/scripts/draft-change-log-entries.sh as a starting point for writing the change log.
  • Run the Prepare release branch workflow.
    • Press the "Run workflow" button, and leave the default branch main selected.
    • Review and merge the two pull requests that it creates (one is targeted to the release branch and one is targeted to main).

Preparing a new 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 regressions, security vulnerabilities, memory leaks and deadlocks.

  • Backport pull request(s) to the release branch.
    • Run the Backport workflow.
    • Press the "Run workflow" button, then select the release branch from the dropdown list, e.g. release/v1.9.x, then enter the pull request number that you want to backport, then click the "Run workflow" button below that.
    • Review and merge the backport pull request that it generates.
  • Merge a pull request to the release branch updating the CHANGELOG.md.
    • The heading for the unreleased entries should be ## Unreleased.
  • Run the Prepare patch release workflow.
    • Press the "Run workflow" button, then select the release branch from the dropdown list, e.g. release/v1.9.x, and click the "Run workflow" button below that.
    • Review and merge the pull request that it creates for updating the version.

Making the release

  • Run the Release workflow.
    • Press the "Run workflow" button, then select the release branch from the dropdown list, e.g. release/v1.9.x, and click the "Run workflow" button below that.
    • This workflow will:
      • Publish the artifacts to Maven Central
      • Generate GitHub Artifact Attestations for the JMX Metrics and JMX Scraper jars
      • Publish a GitHub release with release notes based on the change log and with the jars attached
    • Review and merge the pull request that it creates for updating the change log in main (note that if this is not a patch release then the change log on main may already be up-to-date, in which case no pull request will be created).

Credentials

Same as the core repo, see opentelemetry-java/RELEASING.md#credentials.