From f5807aa71e5d76893a772a4fa9483b71ae638f8a Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 10 Jun 2020 01:21:19 +0200 Subject: [PATCH 01/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 54 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5b58594b98b8..3b7fb28345d3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,7 +14,8 @@ - [Development Procedure](#development-procedure) - [Pull Merge Procedure](#pull-merge-procedure) - [Release Procedure](#release-procedure) - - [Point Release Procedure](#point-release-procedure) + - [Stable Release Update Procedure](#stable-release-update-procedure) + - [Stable Release Updates](#stable-release-updates) - [Code Owner Membership](#code-owner-membership) Thank you for considering making contributions to Cosmos-SDK and related @@ -228,7 +229,7 @@ only pull requests targeted directly against master. - Tag the release (use `git tag -a`) and create a release in Github - Delete the `RC` branches -### Point Release Procedure +### Stable Release Update Procedure At the moment, only a single major release will be supported, so all point releases will be based off of that release. @@ -264,6 +265,55 @@ Finally, when a point release is ready to be made: Note, although we aim to support only a single release at a time, the process stated above could be used for multiple previous versions. +## Stable Release Updates (SRU) + +Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances +and must follow the *Stable Release Update* (or SRU) procedure. + +### Rationale + +Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption, +and by a significantly different demographic of users. During development, changes in the `master` branch +affect SDK users, application developers, early adopters, and other advanced users that elect to use +unstable experimental software at their own risk. + +Conversely, stable release users expect a high degree of stability. They build their applications on it, and the +problems they experience with it could be potentially highly disruptive to their projects and businesses. + +Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them +with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present +a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or +poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt +of regression risks. + +Therefore, the requirements for stable changesets are different than those that are candidate to be merged in +the `master` branch. When preparing future major releases, our aim to design the most elegant, user-friendly and +maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or +renaming packages, reducing code duplication so that we maintain common functions and data structures in one +place rather than leaving them scattered all over the code base. However, once a release is published, the +priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to +be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different +ways in stable releases and `master` branch. + +### What qualifies as SRU + +* **High-impact bugs** + * Bugs that may directly cause a security vulnerability. + * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues + that may cause the core packages or the `x/` modules unusable. + * Bugs that may cause **loss of user's data**. +* Other safe cases: + * Bugs which don't fit in the aforementoned categories for which an obvious safe patch is known. + * Relatively small yet strictly non-breaking changes that introduce forward-compatible client + features to smoothen the migration to successive releases. + +### What does not qualify as SRU + +* State machine changes. +* New features that introduces API breakages (e.g. public functions removal/renaming). +* Cosmetic fixes, such as formatting or linter warning fixes. +* Documentation fixes. + ## Code Owner Membership In the ethos of open source projects, and out of necessity to keep the code From 83e9f7fe88bd00450eccced660a6ba56573b93ac Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 10 Jun 2020 23:20:06 +0200 Subject: [PATCH 02/33] Update stable release update procedure --- CONTRIBUTING.md | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3b7fb28345d3..bf212cf22c3d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -235,26 +235,34 @@ At the moment, only a single major release will be supported, so all point relea off of that release. In order to alleviate the burden for a single person to have to cherry-pick and handle merge conflicts -of all desired backporting PRs to a point release, we instead maintain a living backport branch, where +of all desired backporting PRs to a point release, we instead maintain a living SRU branch, where all desired features and bug fixes are merged into as separate PRs. Example: -Current release is `v0.38.4`. We then maintain a (living) branch `backport/release/v0.38.x`. As PRs -are merged into master, if they wish to be backported into the next `v0.38.x` point release, the -author must: - -1. Add `backport` label -2. Pull latest changes on the desired `backport/release/v*.*.x` branch -3. Create a 2nd PR merging the respective backport PR into `backport/release/v*.*.x` - -This means it is the authors responsibility to fix any merge conflicts, update changelog entries, and -ensure CI passes. If a PR originates from an external contributor, it may be a team members responsibility -to perform this process instead of the original author. +Current release is `v0.38.4`. We then maintain a (living) branch `sru/release/v0.38.N`, given N as +the next patch release number (currently `0.38.5`) for the `0.38` release series. As bugs are fixed +and PRs are merged into `master`, if a contributor wishes the PR to be released as SRU into the +`v0.38.N` point release, the contributor must: + +1. Add `0.38-sru` label +2. Pull latest changes on the desired `sru/release/v0.38.N` branch +3. Create a 2nd PR merging the respective SRU PR into `sru/release/v0.38.N` +4. Update the PR's description and ensure it contains the following information: + - **[Impact]** Explanation of how the bug affects users or developers. + - **[Test Case]** section with detailed instructions on how to reproduce the bug. + - **[Regression Potential]** section with a discussion how regressions are most likely to manifest, or might + manifest even if it's unlikely, as a result of the change. **It is assumed that any SRU candidate PR is + well-tested before it is merged in and has an overall low risk of regression**. + +It is the PR's author's responsibility to fix merge conflicts, update changelog entries, and +ensure CI passes. If a PR originates from an external contributor, it may be a core team member's +responsibility to perform this process instead of the original author. +Lastly, it is core team's responsibility to ensure that the PR meets all the SRU criteria. Finally, when a point release is ready to be made: -1. Create `release/v*.*.x` branch +1. Create `release/v0.38.N` branch 2. Ensure changelog entries are verified 2. Be sure changelog entries are added to `RELEASE_CHANGELOG.md` 3. Add release version date to the changelog From 9c02b26df4c0934cd1ffc1b1e448540a202d6670 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 10 Jun 2020 23:37:30 +0200 Subject: [PATCH 03/33] refine --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bf212cf22c3d..3a44b07144ab 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -285,8 +285,8 @@ and by a significantly different demographic of users. During development, chang affect SDK users, application developers, early adopters, and other advanced users that elect to use unstable experimental software at their own risk. -Conversely, stable release users expect a high degree of stability. They build their applications on it, and the -problems they experience with it could be potentially highly disruptive to their projects and businesses. +Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the +problems they experience with it could be potentially highly disruptive to their projects. Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present From d0697401b67d51059aa94c6f1c91a76c8b5e0b8c Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Thu, 11 Jun 2020 10:50:30 +0200 Subject: [PATCH 04/33] Update CONTRIBUTING.md Co-authored-by: Marko --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3a44b07144ab..0386143a0f95 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -246,7 +246,7 @@ and PRs are merged into `master`, if a contributor wishes the PR to be released `v0.38.N` point release, the contributor must: 1. Add `0.38-sru` label -2. Pull latest changes on the desired `sru/release/v0.38.N` branch +2. Pull latest changes on the desired `sru/release/vX.X.N` branch 3. Create a 2nd PR merging the respective SRU PR into `sru/release/v0.38.N` 4. Update the PR's description and ensure it contains the following information: - **[Impact]** Explanation of how the bug affects users or developers. From 45e2ea37f8804113e1a402a5094c09404386841d Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 22 Jun 2020 10:39:59 +0200 Subject: [PATCH 05/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0386143a0f95..b97ecc791dcc 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -229,7 +229,7 @@ only pull requests targeted directly against master. - Tag the release (use `git tag -a`) and create a release in Github - Delete the `RC` branches -### Stable Release Update Procedure +### Point Release Procedure At the moment, only a single major release will be supported, so all point releases will be based off of that release. From 66413d38e46abf85a2c19d6581e9ddc0c7094683 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 22 Jun 2020 10:40:21 +0200 Subject: [PATCH 06/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b97ecc791dcc..2834e09dc087 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -235,7 +235,7 @@ At the moment, only a single major release will be supported, so all point relea off of that release. In order to alleviate the burden for a single person to have to cherry-pick and handle merge conflicts -of all desired backporting PRs to a point release, we instead maintain a living SRU branch, where +of all desired backporting PRs to a point release, we instead maintain a living backport branch, where all desired features and bug fixes are merged into as separate PRs. Example: From 64649f29d582b2a697b3efc64bfd6287135f8cd0 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 22 Jun 2020 17:54:41 +0200 Subject: [PATCH 07/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2834e09dc087..2015e81f0551 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -273,7 +273,7 @@ Finally, when a point release is ready to be made: Note, although we aim to support only a single release at a time, the process stated above could be used for multiple previous versions. -## Stable Release Updates (SRU) +## Point Releases Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances and must follow the *Stable Release Update* (or SRU) procedure. From 952a3cdf96a764682919f98aec4457b6b9de8151 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Sat, 27 Jun 2020 08:40:59 +0200 Subject: [PATCH 08/33] Move Stable Release policy into a standalone file --- CONTRIBUTING.md | 78 ---------------------------------------- STABLE_RELEASES.md | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 78 deletions(-) create mode 100644 STABLE_RELEASES.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0386143a0f95..e7c695714c75 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -272,81 +272,3 @@ Finally, when a point release is ready to be made: Note, although we aim to support only a single release at a time, the process stated above could be used for multiple previous versions. - -## Stable Release Updates (SRU) - -Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances -and must follow the *Stable Release Update* (or SRU) procedure. - -### Rationale - -Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption, -and by a significantly different demographic of users. During development, changes in the `master` branch -affect SDK users, application developers, early adopters, and other advanced users that elect to use -unstable experimental software at their own risk. - -Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the -problems they experience with it could be potentially highly disruptive to their projects. - -Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them -with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present -a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or -poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt -of regression risks. - -Therefore, the requirements for stable changesets are different than those that are candidate to be merged in -the `master` branch. When preparing future major releases, our aim to design the most elegant, user-friendly and -maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or -renaming packages, reducing code duplication so that we maintain common functions and data structures in one -place rather than leaving them scattered all over the code base. However, once a release is published, the -priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to -be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different -ways in stable releases and `master` branch. - -### What qualifies as SRU - -* **High-impact bugs** - * Bugs that may directly cause a security vulnerability. - * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues - that may cause the core packages or the `x/` modules unusable. - * Bugs that may cause **loss of user's data**. -* Other safe cases: - * Bugs which don't fit in the aforementoned categories for which an obvious safe patch is known. - * Relatively small yet strictly non-breaking changes that introduce forward-compatible client - features to smoothen the migration to successive releases. - -### What does not qualify as SRU - -* State machine changes. -* New features that introduces API breakages (e.g. public functions removal/renaming). -* Cosmetic fixes, such as formatting or linter warning fixes. -* Documentation fixes. - -## Code Owner Membership - -In the ethos of open source projects, and out of necessity to keep the code -alive, the core contributor team will strive to permit special repo privileges -to developers who show an aptitude towards developing with this code base. - -Several different kinds of privileges may be granted however most common -privileges to be granted are merge rights to either part of, or the entire the -code base (though the github `CODEOWNERS` file). The on-boarding process for -new code owners is as follows: On a bi-monthly basis (or more frequently if -agreeable) all the existing code owners will privately convene to discuss -potential new candidates as well as the potential for existing code-owners to -exit or "pass on the torch". This private meeting is to be a held as a -phone/video meeting. Subsequently at the end of the meeting, one of the existing -code owners should open a PR modifying the `CODEOWNERS` file. The other code -owners should then all approve this PR to publicly display their support. - -Only if unanimous consensus is reached among all the existing code-owners will -an invitation be extended to a new potential-member. Likewise, when an existing -member is suggested to be removed/or have their privileges reduced, the member -in question must agree on the decision for their removal or else no action -should be taken. If however, a code-owner is verifiably shown to intentionally -have had acted maliciously or grossly negligent, code-owner privileges may be -stripped with no prior warning or consent from the member in question. - -Earning this privilege should be considered to be no small feat and is by no -means guaranteed by any quantifiable metric. It is a symbol of great trust of -the community of this project. diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md new file mode 100644 index 000000000000..a32a3e1723dd --- /dev/null +++ b/STABLE_RELEASES.md @@ -0,0 +1,88 @@ +# Stable Releases + +The following release series are currently supported and receieve bugfixes: + +* `0.37.x` +* `0.38.x` + +Stable releases continue to receieve bugfixes until they reach End Of Life. +The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub +migrates to a newer release of the Cosmos-SDK. + +## Point Releases + +Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances +and must follow the [Point Release Procedure](CONTRIBUTING.md). + +## Rationale + +Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption, +and by a significantly different demographic of users. During development, changes in the `master` branch +affect SDK users, application developers, early adopters, and other advanced users that elect to use +unstable experimental software at their own risk. + +Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the +problems they experience with it could be potentially highly disruptive to their projects. + +Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them +with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present +a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or +poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt +of regression risks. + +Therefore, the requirements for stable changesets are different than those that are candidate to be merged in +the `master` branch. When preparing future major releases, our aim to design the most elegant, user-friendly and +maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or +renaming packages, reducing code duplication so that we maintain common functions and data structures in one +place rather than leaving them scattered all over the code base. However, once a release is published, the +priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to +be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different +ways in stable releases and `master` branch. + +### What qualifies as SRU + +* **High-impact bugs** + * Bugs that may directly cause a security vulnerability. + * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues + that may cause the core packages or the `x/` modules unusable. + * Bugs that may cause **loss of user's data**. +* Other safe cases: + * Bugs which don't fit in the aforementoned categories for which an obvious safe patch is known. + * Relatively small yet strictly non-breaking changes that introduce forward-compatible client + features to smoothen the migration to successive releases. + +### What does not qualify as SRU + +* State machine changes. +* New features that introduces API breakages (e.g. public functions removal/renaming). +* Cosmetic fixes, such as formatting or linter warning fixes. +* Documentation fixes. + +## Code Owner Membership + +In the ethos of open source projects, and out of necessity to keep the code +alive, the core contributor team will strive to permit special repo privileges +to developers who show an aptitude towards developing with this code base. + +Several different kinds of privileges may be granted however most common +privileges to be granted are merge rights to either part of, or the entire the +code base (though the github `CODEOWNERS` file). The on-boarding process for +new code owners is as follows: On a bi-monthly basis (or more frequently if +agreeable) all the existing code owners will privately convene to discuss +potential new candidates as well as the potential for existing code-owners to +exit or "pass on the torch". This private meeting is to be a held as a +phone/video meeting. Subsequently at the end of the meeting, one of the existing +code owners should open a PR modifying the `CODEOWNERS` file. The other code +owners should then all approve this PR to publicly display their support. + +Only if unanimous consensus is reached among all the existing code-owners will +an invitation be extended to a new potential-member. Likewise, when an existing +member is suggested to be removed/or have their privileges reduced, the member +in question must agree on the decision for their removal or else no action +should be taken. If however, a code-owner is verifiably shown to intentionally +have had acted maliciously or grossly negligent, code-owner privileges may be +stripped with no prior warning or consent from the member in question. + +Earning this privilege should be considered to be no small feat and is by no +means guaranteed by any quantifiable metric. It is a symbol of great trust of +the community of this project. From 4f4bdd680ed5a6256521f0218fe2e498401ab67c Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 30 Jun 2020 00:02:02 +0200 Subject: [PATCH 09/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e3b27a754c1e..6ff453928a2c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,8 +14,7 @@ - [Development Procedure](#development-procedure) - [Pull Merge Procedure](#pull-merge-procedure) - [Release Procedure](#release-procedure) - - [Stable Release Update Procedure](#stable-release-update-procedure) - - [Stable Release Updates](#stable-release-updates) + - [Point Release Procedure](#point-release-procedure) - [Code Owner Membership](#code-owner-membership) Thank you for considering making contributions to Cosmos-SDK and related From 8584b1b7d20940cca5f24fbf48f69e034e658c45 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 30 Jun 2020 00:02:52 +0200 Subject: [PATCH 10/33] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6ff453928a2c..94aed69b0137 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -259,7 +259,7 @@ the next patch release number (currently `0.38.5`) for the `0.38` release series and PRs are merged into `master`, if a contributor wishes the PR to be released as SRU into the `v0.38.N` point release, the contributor must: -1. Add `0.38-sru` label +1. Add `0.38.N-backport` label 2. Pull latest changes on the desired `sru/release/vX.X.N` branch 3. Create a 2nd PR merging the respective SRU PR into `sru/release/v0.38.N` 4. Update the PR's description and ensure it contains the following information: From 00046f5104df4ad4221ef4d848489fa79f62b59a Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:18:24 +0200 Subject: [PATCH 11/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index a32a3e1723dd..30b475a61ebc 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -30,7 +30,7 @@ a low risk of regressions, i.e. even one-line changes could cause unexpected reg poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt of regression risks. -Therefore, the requirements for stable changesets are different than those that are candidate to be merged in +Therefore, the requirements for stable changes are different than those that are candidates to be merged in the `master` branch. When preparing future major releases, our aim to design the most elegant, user-friendly and maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or renaming packages, reducing code duplication so that we maintain common functions and data structures in one From c29e51b44cd343f66115fd88e97e9ccd66f66f02 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:18:41 +0200 Subject: [PATCH 12/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 30b475a61ebc..b0a34e938b63 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -31,7 +31,7 @@ poorly tested code. We never assume that any change, no matter how little or non of regression risks. Therefore, the requirements for stable changes are different than those that are candidates to be merged in -the `master` branch. When preparing future major releases, our aim to design the most elegant, user-friendly and +the `master` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or renaming packages, reducing code duplication so that we maintain common functions and data structures in one place rather than leaving them scattered all over the code base. However, once a release is published, the From 010f09c161024c005015fd81c6f30a5bc491b4bd Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:18:50 +0200 Subject: [PATCH 13/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index b0a34e938b63..4ffd8dd7939b 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -33,7 +33,7 @@ of regression risks. Therefore, the requirements for stable changes are different than those that are candidates to be merged in the `master` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or -renaming packages, reducing code duplication so that we maintain common functions and data structures in one +renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one place rather than leaving them scattered all over the code base. However, once a release is published, the priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different From 1c2d1b5c5c024ea53b765dc40d14ddc9b9a83914 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:19:05 +0200 Subject: [PATCH 14/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 4ffd8dd7939b..489092764cb7 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -65,7 +65,7 @@ alive, the core contributor team will strive to permit special repo privileges to developers who show an aptitude towards developing with this code base. Several different kinds of privileges may be granted however most common -privileges to be granted are merge rights to either part of, or the entire the +privileges to be granted are merge rights to either part of, or the entirety of the code base (though the github `CODEOWNERS` file). The on-boarding process for new code owners is as follows: On a bi-monthly basis (or more frequently if agreeable) all the existing code owners will privately convene to discuss From a67ff4a14b220d84ff4bbb63b40d1e038e36a721 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:20:36 +0200 Subject: [PATCH 15/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 489092764cb7..0fbeaf3f1d41 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -66,7 +66,7 @@ to developers who show an aptitude towards developing with this code base. Several different kinds of privileges may be granted however most common privileges to be granted are merge rights to either part of, or the entirety of the -code base (though the github `CODEOWNERS` file). The on-boarding process for +code base (through the github `CODEOWNERS` file). The on-boarding process for new code owners is as follows: On a bi-monthly basis (or more frequently if agreeable) all the existing code owners will privately convene to discuss potential new candidates as well as the potential for existing code-owners to From 29da9a5d8c49b3239f2fedc0b6d37506b48c48db Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:20:57 +0200 Subject: [PATCH 16/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 0fbeaf3f1d41..db305ef66352 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -32,7 +32,7 @@ of regression risks. Therefore, the requirements for stable changes are different than those that are candidates to be merged in the `master` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and -maintainable SDK possible often entails fundamental changes to the SDK's architecture design, rearranging and/or +maintainable SDK possible which often entails fundamental changes to the SDK's architecture design, rearranging and/or renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one place rather than leaving them scattered all over the code base. However, once a release is published, the priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to From 0a5d5032f58c0b83363b865b82209c8a466c7d7e Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 16:21:07 +0200 Subject: [PATCH 17/33] Update STABLE_RELEASES.md Co-authored-by: billy rennekamp --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index db305ef66352..d334eecc8ff8 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -39,7 +39,7 @@ priority is to minimise the risk caused by changes not strictly required to fix be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different ways in stable releases and `master` branch. -### What qualifies as SRU +### What qualifies as a Stable Release Update (SRU) * **High-impact bugs** * Bugs that may directly cause a security vulnerability. From 4c802e0e0f090dd268d3714b51e49e99f821505d Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Wed, 1 Jul 2020 18:47:09 +0200 Subject: [PATCH 18/33] Update STABLE_RELEASES.md --- STABLE_RELEASES.md | 1 - 1 file changed, 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index d334eecc8ff8..ae17d2c61932 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -56,7 +56,6 @@ ways in stable releases and `master` branch. * State machine changes. * New features that introduces API breakages (e.g. public functions removal/renaming). * Cosmetic fixes, such as formatting or linter warning fixes. -* Documentation fixes. ## Code Owner Membership From fc269c2eba191bc4fab5d821ca8c7cc976408e31 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Fri, 3 Jul 2020 16:38:38 +0200 Subject: [PATCH 19/33] Update STABLE_RELEASES.md --- STABLE_RELEASES.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index ae17d2c61932..8a990c997078 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -9,6 +9,8 @@ Stable releases continue to receieve bugfixes until they reach End Of Life. The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub migrates to a newer release of the Cosmos-SDK. +The `0.38.x` release series will reach End of Life once the `0.39.0` release is published. + ## Point Releases Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances @@ -35,7 +37,7 @@ the `master` branch. When preparing future major releases, our aim is to design maintainable SDK possible which often entails fundamental changes to the SDK's architecture design, rearranging and/or renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one place rather than leaving them scattered all over the code base. However, once a release is published, the -priority is to minimise the risk caused by changes not strictly required to fix qualifying bugs; this tends to +priority is to minimise the risk caused by changes that are not strictly required to fix qualifying bugs; this tends to be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different ways in stable releases and `master` branch. From e6313ea99ce8f7ce5a419cba11977b68ff1d9295 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 00:00:57 +0200 Subject: [PATCH 20/33] start working on 0.39 release series policy --- STABLE_RELEASES.md | 44 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 8a990c997078..c1d2d487e968 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -2,8 +2,8 @@ The following release series are currently supported and receieve bugfixes: -* `0.37.x` -* `0.38.x` +* **0.37** +* **0.39 "Launchpad"** Stable releases continue to receieve bugfixes until they reach End Of Life. The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub @@ -49,7 +49,7 @@ ways in stable releases and `master` branch. that may cause the core packages or the `x/` modules unusable. * Bugs that may cause **loss of user's data**. * Other safe cases: - * Bugs which don't fit in the aforementoned categories for which an obvious safe patch is known. + * Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known. * Relatively small yet strictly non-breaking changes that introduce forward-compatible client features to smoothen the migration to successive releases. @@ -87,3 +87,41 @@ stripped with no prior warning or consent from the member in question. Earning this privilege should be considered to be no small feat and is by no means guaranteed by any quantifiable metric. It is a symbol of great trust of the community of this project. + +# 0.37 + +The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub +migrates to a newer release of the Cosmos-SDK. + +# 0.38 + +Discontinued since **0.39.0** is published. + +# 0.39 - The Launchpad Release Series + +The **0.39 Launchpad** release series will be supported until 6 months after **0.40.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release. + +## 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: + + * **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**. + +## What pull requests will NOT be automatically included in stable point-releases + +As generic rule, 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's source code. + + 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 + + How to ask for a **Stable Release Exception**. + + TODO + From 358c1e5c17249e0132b26cd5978464babd258eb6 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 00:02:45 +0200 Subject: [PATCH 21/33] Update STABLE_RELEASES.md --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index c1d2d487e968..547c9b45f70b 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -112,7 +112,7 @@ Pull requests that fix bugs that fall in the following categories do not require ## What pull requests will NOT be automatically included in stable point-releases -As generic rule, the following changes will **NOT** be automatically accepted into 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's source code. From f9ae335052e7f7287de976b5413f93099a507b12 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 12:57:18 +0200 Subject: [PATCH 22/33] add Stable Release Exception procedure --- STABLE_RELEASES.md | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 547c9b45f70b..187c1f4a43b4 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -119,9 +119,29 @@ As rule of thumb, the following changes will **NOT** be automatically accepted i 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 - - How to ask for a **Stable Release Exception**. - - TODO + ## 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 bugfixes for stable releases without first testing them in `master`. Please apply the label [0.39 (Launchpad)](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%29) 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 `release/launchpad/0.39.X` branch, being `X` the Launchpad's next point-release and the PR included in the `0.39.X` respective milestone. + +### Stable Release Exception - Bug template + +``` +#### Impact + +Brief xplanation of the effects of the bug on users and a justification for backporting the fix to the stable release. + +#### Test Case + +Detailed instructions on how to reproduce the bug on Launchpad's most recently published point-release. + +#### Regression Potential + +Explanation on how regressions might manifest - even if it's unlikely. +It is assumed that stable release fixes are well-tested and they come with a low risk of regressions. +It's crucial to make the effort of thinking about what could happen in case a regression emerges. +``` From 9de8288ace052e31c0d59897f6d86d8ad2689109 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 15:39:21 +0200 Subject: [PATCH 23/33] changes --- STABLE_RELEASES.md | 40 +++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 23 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 187c1f4a43b4..5f9314f0c968 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -1,15 +1,22 @@ # Stable Releases -The following release series are currently supported and receieve bugfixes: +*Stable Release Series* continue to receieve bugfixes until they reach **End Of Life**. -* **0.37** -* **0.39 "Launchpad"** +Only the following release series are currently supported and receieve bugfixes: -Stable releases continue to receieve bugfixes until they reach End Of Life. The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub migrates to a newer release of the Cosmos-SDK. -The `0.38.x` release series will reach End of Life once the `0.39.0` release is published. +* **0.37** will continue receiving bugfixes until the Cosmos Hub migrates to a newer release series of the Cosmos-SDK. +* **0.39 «Launchpad»** will be supported until 6 months after **0.40.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release. + +The **0.39 «Launchpad»** 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.39 «Launchpad»** ## Point Releases @@ -88,19 +95,6 @@ Earning this privilege should be considered to be no small feat and is by no means guaranteed by any quantifiable metric. It is a symbol of great trust of the community of this project. -# 0.37 - -The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub -migrates to a newer release of the Cosmos-SDK. - -# 0.38 - -Discontinued since **0.39.0** is published. - -# 0.39 - The Launchpad Release Series - -The **0.39 Launchpad** release series will be supported until 6 months after **0.40.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release. - ## 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: @@ -115,18 +109,18 @@ Pull requests that fix bugs that fall in the following categories do not require 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's source code. + * **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code. 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 bugfixes for stable releases without first testing them in `master`. Please apply the label [0.39 (Launchpad)](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%29) to the issue. +## 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 bugfixes for stable releases without first testing them in `master`. Please apply the label [0.39 «Launchpad»](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%29) 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 `release/launchpad/0.39.X` branch, being `X` the Launchpad's next point-release and the PR included in the `0.39.X` respective milestone. +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/launchpad/0.39.X` being `X` the Launchpad's upcoming point-release) and the PR included in the point-release's respective milestone (e.g. `0.39.5`). ### Stable Release Exception - Bug template From f1122c4112d94827f76f0701ee444509141e460b Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 15:44:47 +0200 Subject: [PATCH 24/33] receieve -> receive --- STABLE_RELEASES.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 5f9314f0c968..5c2702f810be 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -1,8 +1,8 @@ # Stable Releases -*Stable Release Series* continue to receieve bugfixes until they reach **End Of Life**. +*Stable Release Series* continue to receive bugfixes until they reach **End Of Life**. -Only the following release series are currently supported and receieve bugfixes: +Only the following release series are currently supported and receive bugfixes: The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub migrates to a newer release of the Cosmos-SDK. From 2218fc41b6ca58afe722b57ea106e232fdf6c43a Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 15:47:51 +0200 Subject: [PATCH 25/33] verifiably -> demonstrably --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 5c2702f810be..2437d9b53106 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -87,7 +87,7 @@ Only if unanimous consensus is reached among all the existing code-owners will an invitation be extended to a new potential-member. Likewise, when an existing member is suggested to be removed/or have their privileges reduced, the member in question must agree on the decision for their removal or else no action -should be taken. If however, a code-owner is verifiably shown to intentionally +should be taken. If however, a code-owner is demonstrably shown to intentionally have had acted maliciously or grossly negligent, code-owner privileges may be stripped with no prior warning or consent from the member in question. From b7d242204c48c76721d865ef8029abc5ee8b34ec Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Tue, 7 Jul 2020 15:49:47 +0200 Subject: [PATCH 26/33] bugfixes -> bug fixes (aspell's checks) --- STABLE_RELEASES.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 2437d9b53106..b4c957960982 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -1,13 +1,13 @@ # Stable Releases -*Stable Release Series* continue to receive bugfixes until they reach **End Of Life**. +*Stable Release Series* continue to receive bug fixes until they reach **End Of Life**. -Only the following release series are currently supported and receive bugfixes: +Only the following release series are currently supported and receive bug fixes: -The `0.37.x` release series will continue receiving bugfixes until the Cosmos Hub +The `0.37.x` release series will continue receiving bug fixes until the Cosmos Hub migrates to a newer release of the Cosmos-SDK. -* **0.37** will continue receiving bugfixes until the Cosmos Hub migrates to a newer release series of the Cosmos-SDK. +* **0.37** will continue receiving bug fixes until the Cosmos Hub migrates to a newer release series of the Cosmos-SDK. * **0.39 «Launchpad»** will be supported until 6 months after **0.40.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release. The **0.39 «Launchpad»** release series is maintained in compliance with the **Stable Release Policy** as described in this document. @@ -115,7 +115,7 @@ As rule of thumb, the following changes will **NOT** be automatically accepted i ## 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 bugfixes for stable releases without first testing them in `master`. Please apply the label [0.39 «Launchpad»](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%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 [0.39 «Launchpad»](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%29) 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. From aac2fda1916b44b8d4f3fe966a56f777a4636a29 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 15:52:41 +0200 Subject: [PATCH 27/33] Add stanza re: stable release managers --- STABLE_RELEASES.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index b4c957960982..6786decfbbaf 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -139,3 +139,16 @@ Explanation on how regressions might manifest - even if it's unlikely. It is assumed that stable release fixes are well-tested and they come with a low risk of regressions. It's crucial to make the effort of thinking about what could happen in case a regression emerges. ``` + +## Stable Release Managers + +The **Stable Release Managers** evaluate and approve or reject updates and backports to Cosmos-SDK Stable Release series, +according to the [stable release policy](#stable-release-policy) and [release procedure](#stable-release-exception-procedure). +Decisions are made by consensus. + +Their responsibilites include: + * Driving the Stable Release Exception process. + * Approving/rejecting proposed changes to a stable release series. + * Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md). + +The Stable Release Managers are appointed by the Interchain Foundation. From 00c3caf9672a2164d4b277a1e7f3eb2e65dc40b6 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 20:56:46 +0200 Subject: [PATCH 28/33] move code ownership stanza to contributing.md --- STABLE_RELEASES.md | 29 ----------------------------- 1 file changed, 29 deletions(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 6786decfbbaf..f306fecff76c 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -66,35 +66,6 @@ ways in stable releases and `master` branch. * New features that introduces API breakages (e.g. public functions removal/renaming). * Cosmetic fixes, such as formatting or linter warning fixes. -## Code Owner Membership - -In the ethos of open source projects, and out of necessity to keep the code -alive, the core contributor team will strive to permit special repo privileges -to developers who show an aptitude towards developing with this code base. - -Several different kinds of privileges may be granted however most common -privileges to be granted are merge rights to either part of, or the entirety of the -code base (through the github `CODEOWNERS` file). The on-boarding process for -new code owners is as follows: On a bi-monthly basis (or more frequently if -agreeable) all the existing code owners will privately convene to discuss -potential new candidates as well as the potential for existing code-owners to -exit or "pass on the torch". This private meeting is to be a held as a -phone/video meeting. Subsequently at the end of the meeting, one of the existing -code owners should open a PR modifying the `CODEOWNERS` file. The other code -owners should then all approve this PR to publicly display their support. - -Only if unanimous consensus is reached among all the existing code-owners will -an invitation be extended to a new potential-member. Likewise, when an existing -member is suggested to be removed/or have their privileges reduced, the member -in question must agree on the decision for their removal or else no action -should be taken. If however, a code-owner is demonstrably shown to intentionally -have had acted maliciously or grossly negligent, code-owner privileges may be -stripped with no prior warning or consent from the member in question. - -Earning this privilege should be considered to be no small feat and is by no -means guaranteed by any quantifiable metric. It is a symbol of great trust of -the community of this project. - ## 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: From 434049e123191cebfcde9d5d93e849b375dca3e8 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 20:57:19 +0200 Subject: [PATCH 29/33] reinstante Code Owner Membership section --- CONTRIBUTING.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88ac4a0601ce..35e4705c04c6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -286,3 +286,32 @@ Finally, when a point release is ready to be made: Note, although we aim to support only a single release at a time, the process stated above could be used for multiple previous versions. + +## Code Owner Membership + +In the ethos of open source projects, and out of necessity to keep the code +alive, the core contributor team will strive to permit special repo privileges +to developers who show an aptitude towards developing with this code base. + +Several different kinds of privileges may be granted however most common +privileges to be granted are merge rights to either part of, or the entirety of the +code base (through the github `CODEOWNERS` file). The on-boarding process for +new code owners is as follows: On a bi-monthly basis (or more frequently if +agreeable) all the existing code owners will privately convene to discuss +potential new candidates as well as the potential for existing code-owners to +exit or "pass on the torch". This private meeting is to be a held as a +phone/video meeting. Subsequently at the end of the meeting, one of the existing +code owners should open a PR modifying the `CODEOWNERS` file. The other code +owners should then all approve this PR to publicly display their support. + +Only if unanimous consensus is reached among all the existing code-owners will +an invitation be extended to a new potential-member. Likewise, when an existing +member is suggested to be removed/or have their privileges reduced, the member +in question must agree on the decision for their removal or else no action +should be taken. If however, a code-owner is demonstrably shown to intentionally +have had acted maliciously or grossly negligent, code-owner privileges may be +stripped with no prior warning or consent from the member in question. + +Earning this privilege should be considered to be no small feat and is by no +means guaranteed by any quantifiable metric. It is a symbol of great trust of +the community of this project. From 17e3e635774304b7c26a3b090f44f6970e747fe2 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 21:17:36 +0200 Subject: [PATCH 30/33] update stable release managers --- STABLE_RELEASES.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index f306fecff76c..29c110ba26d1 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -123,3 +123,9 @@ Their responsibilites include: * Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md). The Stable Release Managers are appointed by the Interchain Foundation. + +*Stable Release Managers* for the **0.39 «Launchpad»** release series follow: + +* @alessio - Alessio Treglia +* @clevinson - Cory Levinson- +* @ethanfrey - Ethan Frey From 77453902ac6393c1cc0189e9f97e24a91c614669 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 23:35:43 +0100 Subject: [PATCH 31/33] Update STABLE_RELEASES.md Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 29c110ba26d1..67c1ad7a58b8 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -12,7 +12,7 @@ migrates to a newer release of the Cosmos-SDK. The **0.39 «Launchpad»** release series is maintained in compliance with the **Stable Release Policy** as described in this document. -# Stable Release Policy +## Stable Release Policy This policy presently applies *only* to the following release series: From 0a6d137b1f8e13e30af37b012c0e6edf4ee88f23 Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 23:35:54 +0100 Subject: [PATCH 32/33] Update STABLE_RELEASES.md Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 67c1ad7a58b8..54295db4e17a 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -18,7 +18,7 @@ This policy presently applies *only* to the following release series: * **0.39 «Launchpad»** -## Point Releases +### Point Releases Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances and must follow the [Point Release Procedure](CONTRIBUTING.md). From e573b299bebf077423028a16683be551b81516ec Mon Sep 17 00:00:00 2001 From: Alessio Treglia Date: Mon, 13 Jul 2020 23:36:01 +0100 Subject: [PATCH 33/33] Update STABLE_RELEASES.md Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> --- STABLE_RELEASES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md index 54295db4e17a..fd6a88213557 100644 --- a/STABLE_RELEASES.md +++ b/STABLE_RELEASES.md @@ -23,7 +23,7 @@ This policy presently applies *only* to the following release series: Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances and must follow the [Point Release Procedure](CONTRIBUTING.md). -## Rationale +### Rationale Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption, and by a significantly different demographic of users. During development, changes in the `master` branch