Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add release workflows #48

Merged
merged 4 commits into from
Jan 5, 2023
Merged

Add release workflows #48

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a6cf7b4
Add release workflows
gaiksaya Jan 5, 2023
0d9e4aa
Add release documentation
gaiksaya Jan 5, 2023
332f08c
Add release documentation
gaiksaya Jan 5, 2023
4f289ee
Modify version
gaiksaya Jan 5, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
- [Overview](#overview)
- [Branching](#branching)
- [Release Branching](#release-branching)
- [Feature Branches](#feature-branches)
- [Release Labels](#release-labels)
- [Releasing](#releasing)

## 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.
YANG-DB marked this conversation as resolved.
Show resolved Hide resolved

### Feature Branches

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.

## 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.

## Releasing

The release process is standard across repositories in this org and is run by a release manager volunteering from amongst [maintainers](MAINTAINERS.md).

1. Create a tag, e.g. 1.0.0, and push it to this GitHub repository.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tag example should be 1.0.0.0 in this case

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since sql-jdbc is a stand-alone component shouldn't the tag be 1.0.0?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then maybe it wasn't done correctly before, last release was 1.1.0.1 for some reason https://artifacts.opensearch.org/opensearch-clients/jdbc/opensearch-sql-jdbc-1.1.0.1.jar

should new releases be 1.2.0.0 or 1.2.0?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would take input from @dblock @CEHENKLE @bbarani regarding this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be 1.2.0.0 IMO...

1. The [release-drafter.yml](.github/workflows/release-drafter.yml) will be automatically kicked off and a draft release will be created.
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.
1. Once the above release workflow is successful, the drafted release on GitHub is published automatically.
1. Increment "version" in [build.gradle](./build.gradle) to the next iteration, e.g. v2.1.1. See [example](https://github.com/opensearch-project/sql-jdbc/pull/11).