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.

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

doc: refactor the release process and release management guideline #53

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

FeynmanZhou
Copy link
Member

fix #52


## Release process

Before cutting a release for a project, ORAS project maintainers need to open a Pull Request to update version. The release request PR could be merged after a majority of approval from the sub-project maintainers.
Copy link

Choose a reason for hiding this comment

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

Is it a two-thirds supermajority or just more than one-half?

Copy link
Contributor

Choose a reason for hiding this comment

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

One-half is good enough since we only have 5 maintainers for oras.

One-half means 3 / 5 where two-thirds means 4 / 5.

Copy link
Contributor

Choose a reason for hiding this comment

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

Precisely,

#Maintainers One-half Rate Two-thirds Rate
1 1 100% 1 100%
2 2 100% 2 100%
3 2 66.7% 2 66.7%
4 3 75% 3 75%
5 3 60% 4 80%
6 4 66.7% 4 66.7%
7 4 57.1% 5 71.4%
8 5 62.5% 6 75%
9 5 55.6% 6 66.7%
10 6 60% 7 70%
11 6 54.5% 8 72.7%
12 7 58.3% 8 66.7%

Copy link
Contributor

Choose a reason for hiding this comment

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

The truth is that we don't have many maintainers for oras.

## Glossary of Terms

- **X.Y.Z** refers to the version (based on git tag) of ORAS sub-project that is released.
- **Breaking changes** refer to schema changes, flag changes, and behavior changes of ORAS sub-projects that may require existing content to be upgraded and may also introduce changes that could break backward compatibility.
Copy link
Contributor

Choose a reason for hiding this comment

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

I want to call out that breaking changes to experimental features are not considered as breaking changes.


## Glossary of Terms

- **X.Y.Z** refers to the version (based on git tag) of ORAS sub-project that is released.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is that vX.Y.Z or X.Y.Z?


### Minor Releases

- **ALPHA:** X.Y.0-alpha.W, W >= 0 (Branch : main)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why W >= 0? The version 2.0.0-alpha.0 does not make sense to me so as 2.0.0-rc.0.
Should it be W > 0?


## Supported Releases

We expect to "support" n (current) and n-1 major.minor releases. "Support" means we expect users to be running that version in production. For example, when v1.3.0 comes out, v1.1.x will no longer be supported for patches and we encourage users to upgrade to a supported version as soon as possible. Support will be provided best effort by the maintainers via GitHub issues and pull requests.
Copy link
Contributor

Choose a reason for hiding this comment

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

What if v2.0.0 comes out?


## Governance

This ORAS project governance model is described [here][governance]
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
This ORAS project governance model is described [here][governance]
This ORAS project governance model is described [here][governance].

Comment on lines +72 to +74
[owner]: https://github.com/oras-project/community/blob/main/governance/GOVERNANCE.md#oras-org-owners
[sub-project-owner]: https://github.com/oras-project/community/blob/main/governance/GOVERNANCE.md#subproject-owners
[governance]: ./GOVERNANCE.md
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's make those links consistent.


## Release process

Before cutting a release for a project, ORAS project maintainers need to open a Pull Request to update version. The release request PR could be merged after a majority of approval from the sub-project maintainers.
Copy link
Contributor

Choose a reason for hiding this comment

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

One-half is good enough since we only have 5 maintainers for oras.

One-half means 3 / 5 where two-thirds means 4 / 5.


## Release process

Before cutting a release for a project, ORAS project maintainers need to open a Pull Request to update version. The release request PR could be merged after a majority of approval from the sub-project maintainers.
Copy link
Contributor

Choose a reason for hiding this comment

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

Precisely,

#Maintainers One-half Rate Two-thirds Rate
1 1 100% 1 100%
2 2 100% 2 100%
3 2 66.7% 2 66.7%
4 3 75% 3 75%
5 3 60% 4 80%
6 4 66.7% 4 66.7%
7 4 57.1% 5 71.4%
8 5 62.5% 6 75%
9 5 55.6% 6 66.7%
10 6 60% 7 70%
11 6 54.5% 8 72.7%
12 7 58.3% 8 66.7%


## Release process

Before cutting a release for a project, ORAS project maintainers need to open a Pull Request to update version. The release request PR could be merged after a majority of approval from the sub-project maintainers.
Copy link
Contributor

Choose a reason for hiding this comment

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

The truth is that we don't have many maintainers for oras.

@FeynmanZhou FeynmanZhou changed the title doc: refactor the release process guideline doc: refactor the release process and release management guideline Aug 1, 2023
@TerryHowe
Copy link
Member

Can we revive this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor the Release process guideline
4 participants