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

Clarified branching and versioning for plugins. #33

Merged
merged 2 commits into from
Aug 23, 2021
Merged

Clarified branching and versioning for plugins. #33

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ac66144
Clarified branching and versioning for plugins.
dblock Aug 19, 2021
eb83b9d
Clarified 3 branches.
dblock Aug 23, 2021
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
32 changes: 25 additions & 7 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,9 @@
- [Overview](#overview)
- [Branching](#branching)
- [Release Branching](#release-branching)
- [Feature Branches](#feature-branches)
- [OpenSearch Branching](#opensearch-branching)
- [Plugin Branching](#plugin-branching)
- [Versioning](#versioning)
- [Feature Branches](#feature-branches)
- [Release Labels](#release-labels)
- [Releasing](#releasing)
- [Backporting](#backporting)
Expand All @@ -12,16 +14,32 @@ This document explains the release strategy for artifacts in this organization.

## Branching

### Release Branching
Projects create a new branch when they need to start working on 2 separate versions of the product, with the `main` branch being the furthermost release.

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

* **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`.
[OpenSearch](https://github.com/opensearch-project/OpenSearch) typically tracks 3 releases in parallel. For example, given the last major release of 1.0, OpenSearch in this organization maintains the following active branches.

* **main**: The _next major_ release, currently 2.0. This is the branch where all merges take place and code moves fast.
* **1.x**: The _next minor_ release, currently 1.1. Once a change is merged into `main`, decide whether to backport it to `1.x`.
* **1.0**: The _current_ release, currently 1.0. In between minor releases, only hotfixes (e.g. security) are backported to `1.0`. The next release out of this branch will be 1.0.1.

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.

### Plugin Branching

Plugins, such as [job-scheduler](https://github.com/opensearch-project/job-scheduler) aren't as active as OpenSearch, and typically track 2 releases in parallel instead of 3. For example, given the last major release of 1.0, job-scheduler maintains the following active branches.
Copy link
Member

Choose a reason for hiding this comment

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

I understand why we'd like to reduce it to 2 branches.
We should communicate to plugins and remove 1.x branches if they've already created.

Copy link
Member Author

@dblock dblock Aug 23, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

I actually don't think a 1.x branch is a bad idea. It will make things easier to merge. Text below talks about that.

Copy link
Member

Choose a reason for hiding this comment

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

Can we explicitly add that 1,x is optional for plugins?

Copy link
Member Author

Choose a reason for hiding this comment

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

But it's not. What's optional is that you work on the 1.x branch to do active development. Which is explained in the example right below this paragraph.

Copy link
Member

Choose a reason for hiding this comment

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

It seems to have confused two different readers, so perhaps things are not clear?

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right. See my update in eb83b9d


* **main**: The _next_ release, currently 1.1. This is the branch where all merges take place and code moves fast.
* **1.0**: The _current_ release, currently 1.0. This branch's parent is `1.x` to make future merges easier. 'In between minor releases, only hotfixes (e.g. security) are backported to `1.0`. The next release out of this branch will be 1.0.1.

### Versioning

Versions are incremented as soon as development starts on a given version to avoid confusion. In the examples above versions are as follows.

* OpenSearch: `main` = 2.0, `1.x` = 1.1, and `1.0` = 1.0
* job-scheduler: `main` = 1.1, `1.0` = 1.0

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