Skip to content

RELEASING.md

Latest commit

 

History

History
63 lines (40 loc) · 4.06 KB

RELEASING.md

File metadata and controls

63 lines (40 loc) · 4.06 KB
Raw

Overview

This document explains the release strategy for artifacts in this organization.

Branching

Release Branching

Given the current major release of 1.0, projects in this organization maintain the following active branches.

  • main: The next major release. This is the branch where all merges take place and code moves fast.
  • 1.x: The next minor release. Once a change is merged into main, decide whether to backport it to 1.x.
  • 1.0: The current release. In between minor releases, only hotfixes (e.g. security) are backported to 1.0.

Label PRs with the next major version label (e.g. 2.0.0) and merge changes into main. Label PRs that you believe need to be backported as 1.x and 1.0. Backport PRs by checking out the versioned branch, cherry-pick changes and open a PR against each target backport branch.

Feature Branches

Do not creating branches in the upstream repo, use your fork, for the exception of long lasting feature branches that require active collaboration from multiple developers. Name feature branches feature/<thing>. Once the work is merged to main, please make sure to delete the feature branch.

Release Labels

Repositories create consistent release labels, such as v1.0.0, v1.1.0 and v2.0.0, as well as patch and backport. Use release labels to target an issue or a PR for a given release. See Triage Open Issues for more information on triaging issues.

Releasing

The release process is standard across repositories in this org and is run by a release manager volunteering from amongst MAINTAINERS.

  1. Ensure that the version in version.go is correct for the next release.

  2. For major version releases, ensure that all references are up-to-date, e.g. github.com/opensearch-project/opensearch-go/v3, see opensearch-go#444.

  3. Edit the CHANGELOG and replace the Unreleased section with the version about to be released.

  4. Add a comparison link to the new version at the bottom of the CHANGELOG.

  5. Create a pull request with the changes into main, e.g. opensearch-go#443.

  6. Once the PR from step 5 is merged, request a signed release tag. Contributors cannot push signed tags, so open a [GitHub Request] Tag new opensearch-go vX.Y.Z release issue in the opensearch-project/.github repo. Fill out the request form based on the previous release (e.g. opensearch-project/.github#592). A member of @opensearch-project/admin creates the signed tag, which makes the new version available on pkg.go.dev.

  7. Once the tag exists, draft and publish a new GitHub release from it, using the CHANGELOG section for that version as the release notes.

  8. Create a new Unreleased section in the CHANGELOG, increment version in version.go to the next developer iteration (e.g. 4.3.1), and make a pull request with this change into main, e.g. opensearch-go#448.

    ## [Unreleased]

### Added

### Changed

### Deprecated

### Removed

### Fixed

### Security

### Dependencies

  9. Run go list with the new version to refresh pkg.go.dev, e.g. go list -m github.com/opensearch-project/opensearch-go/v5@v5.0.0.