|
| 1 | +- [Overview](#overview) |
| 2 | +- [Branching](#branching) |
| 3 | + - [Release Branching](#release-branching) |
| 4 | + - [Feature Branches](#feature-branches) |
| 5 | +- [Release Labels](#release-labels) |
| 6 | +- [Releasing](#releasing) |
| 7 | + |
| 8 | +## Overview |
| 9 | + |
| 10 | +This document explains the release strategy for artifacts in this organization. |
| 11 | + |
| 12 | +## Branching |
| 13 | + |
| 14 | +### Release Branching |
| 15 | + |
| 16 | +Given the current major release of 1.0, projects in this organization maintain the following active branches. |
| 17 | + |
| 18 | +* **main**: The next _major_ release. This is the branch where all merges take place and code moves fast. |
| 19 | +* **1.x**: The next _minor_ release. Once a change is merged into `main`, decide whether to backport it to `1.x`. |
| 20 | +* **1.0**: The _current_ release. In between minor releases, only hotfixes (e.g. security) are backported to `1.0`. |
| 21 | + |
| 22 | +Label PRs with the next major version label (e.g. `v2.0.0.0`) and merge changes into `main`. Label PRs that you believe need to be backported as `backport 1.x` and `backport 1.0`. Backport PRs by checking out the versioned branch, cherry-pick changes and open a PR against each target backport branch. |
| 23 | + |
| 24 | +### Feature Branches |
| 25 | + |
| 26 | +Do not create 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. |
| 27 | + |
| 28 | +## Release Labels |
| 29 | + |
| 30 | +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. |
| 31 | + |
| 32 | +## Releasing |
| 33 | + |
| 34 | +The release process is standard across repositories in this org and is run by a release manager volunteering from amongst [maintainers](MAINTAINERS.md). |
| 35 | + |
| 36 | +1. Create a tag, e.g. 1.0.0.0, and push it to this GitHub repository. |
| 37 | +1. The [release-drafter.yml](.github/workflows/release-drafter.yml) will be automatically kicked off and a draft release will be created. |
| 38 | +1. This draft release triggers the [jenkins release workflow](https://build.ci.opensearch.org/job/sql-jdbc-release) as a result of which the driver is released on [maven central](https://search.maven.org/search?q=org.opensearch.driver). Please note that the release workflow is triggered only if created release is in draft state. |
| 39 | +1. Once the above release workflow is successful, the drafted release on GitHub is published automatically. |
| 40 | +1. Increment "version" in [build.gradle](./build.gradle) to the next iteration, e.g. 1.0.0.1 See [example](https://github.com/opensearch-project/sql-jdbc/pull/11). |
0 commit comments