Skip to content

Latest commit

 

History

History
67 lines (51 loc) · 3.72 KB

RELEASING.md

File metadata and controls

67 lines (51 loc) · 3.72 KB
Raw

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 Sonatype OSS snapshots repository.

Preparing a new major or minor release

  • Close the release milestone if there is one.
  • Merge a pull request to main updating the CHANGELOG.md.
    • The heading for the release should include the release version but not the release date, e.g. ## Version 1.9.0 (unreleased).
    • Use .github/scripts/draft-change-log-entries.sh as a starting point for writing the change log.
  • Run the Prepare release branch workflow.
  • Review and merge the two pull requests that it creates (one is targeted to the release branch and one is targeted to the main branch).

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, 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 release should include the release version but not the release date, e.g. ## Version 1.9.1 (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.

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 and will publish a GitHub release with release notes based on the change log and with the jmx metrics jar attached.
  • Review and merge the pull request that the release workflow creates against the release branch which adds the release date to the change log.

After the release

Run the Merge change log to main 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 will create a pull request that merges the change log updates from the release branch back to main.
  • Review and merge the pull request that it creates.
  • This workflow will fail if there have been conflicting change log updates introduced in main, in which case you will need to merge the change log updates manually and send your own pull request against main.