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

chore: Update STABLE_RELEASES for 0.43 #9931

Merged
merged 4 commits into from
Aug 16, 2021
Merged

chore: Update STABLE_RELEASES for 0.43 #9931

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
212426d
update versions
amaury1093 Aug 13, 2021
d4241b8
Add features and CLI
amaury1093 Aug 13, 2021
a30841f
Add CLI-breaking changes
amaury1093 Aug 13, 2021
7d9012c
Merge branch 'master' into am/stable-releases
alexanderbez Aug 16, 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: 21 additions & 11 deletions STABLE_RELEASES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,16 +4,16 @@

Only the following release series are currently supported and receive bug fixes:

* **0.39 «Launchpad»** will be supported until 6 months after **0.42.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
* **0.42 «Stargate»** is the latest stable release.
* **0.42 «Stargate»** will be supported until 6 months after **0.43.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
* **0.43 «Stargate»** is the latest stable release.

The **0.42 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.
The **0.43 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.

## Stable Release Policy

This policy presently applies *only* to the following release series:

* **0.42 «Stargate»**
* **0.43 «Stargate»**

### Point Releases

Expand Down Expand Up @@ -47,7 +47,7 @@ ways in stable releases and `master` branch.

### Migrations

To smoothen the update to the latest stable release, the SDK includes a set of CLI commands for managing migrations between SDK versions, under the `migrate` subcommand. Only migration scripts between stable releases are included. For the current release, **0.39 «Launchpad»** and later migrations are supported.
To smoothen the update to the latest stable release, the SDK includes a set of CLI commands for managing migrations between SDK versions, under the `migrate` subcommand. Only migration scripts between stable releases are included. For the current release, **0.42 «Stargate»** and later migrations are supported.

### What qualifies as a Stable Release Update (SRU)

Expand All @@ -58,43 +58,53 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
* Bugs that may cause **loss of user's data**.
* Other safe cases:
* Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
* Relatively small yet strictly non-breaking features with strong support from the community.
Copy link
Collaborator

Choose a reason for hiding this comment

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

very good framing 👍

* Relatively small yet strictly non-breaking changes that introduce forward-compatible client
features to smoothen the migration to successive releases.
* Relatively small yet strictly non-breaking CLI improvements.

### What does not qualify as SRU

* State machine changes.
* New features that introduces API breakages (e.g. public functions removal/renaming).
* Breaking changes in Protobuf definitions, as specified in [ADR-044](./docs/architecture/adr-044-protobuf-updates-guidelines.md).
* Changes that introduces API breakages (e.g. public functions and interfaces removal/renaming).
* Client-breaking changes in gRPC and HTTP request and response types.
* CLI-breaking changes.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We didn't decide if we're okay to backport CLI-breaking changes. I've heard both opinions, for and against.

My personal opinion is to forbid backporting CLI-breaking changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think lines 72, and 70 should have an exception carved out explicitly in the case of bugs

Copy link
Contributor Author

@amaury1093 amaury1093 Aug 16, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

@ValarDragon The way it's framed right now, 70-72 are breaking changes that should not go in a "Stable Release Update".

In case of breaking bugs, they are handled by SRE:

In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a Stable Release Exception.
** describe Stable Release Exception **

* Cosmetic fixes, such as formatting or linter warning fixes.

## What pull requests will be included in stable point-releases

Pull requests that fix bugs that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:
Pull requests that fix bugs and add features that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:

* **Severe regressions**.
* Bugs that may cause **client applications** to be **largely unusable**.
* Bugs that may cause **state corruption or data loss**.
* Bugs that may directly or indirectly cause a **security vulnerability**.
* Non-breaking features that are strongly requested by the community.
* Non-breaking CLI improvements that are strongly requested by the community.

## What pull requests will NOT be automatically included in stable point-releases

As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases:

* **State machine changes**.
* **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
* **Protobug-breaking changes**, as specified in [ADR-044](./docs/architecture/adr-044-protobuf-updates- guidelines.md).
* **Client-breaking changes**, i.e. changes that prevent gRPC, HTTP and RPC clients to continue interacting with the node without any change.
* **API-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
* **CLI-breaking changes**, i.e. changes that require usage changes for CLI users.

In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a *Stable Release Exception*.

## Stable Release Exception - Procedure

1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [0.42 «Stargate»](https://github.com/cosmos/cosmos-sdk/labels/0.42%20LTS%20%28Stargate%29) to the issue.
1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [v0.43](https://github.com/cosmos/cosmos-sdk/milestone/26) to the issue.
2. Add a comment to the issue and ensure it contains the following information (see the bug template below):

* **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
* A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
* A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.

3. **Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.42.x`) and the PR included in the point-release's respective milestone (e.g. `0.42.5`).
3. **Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.43.x`) and the PR included in the point-release's respective milestone (e.g. `v0.43.5`).

### Stable Release Exception - Bug template

Expand Down Expand Up @@ -129,5 +139,5 @@ Their responsibilites include:
The Stable Release Managers are appointed by the Interchain Foundation. Currently residing Stable Release Managers:

* @clevinson - Cory Levinson
* @amaurym - Amaruy Martiny
* @amaurym - Amaury Martiny
* @robert-zaremba - Robert Zaremba