From 3f998fa4ab6a7683de5fe558ef2dcfcc620c817d Mon Sep 17 00:00:00 2001 From: Jonathan Rainville Date: Tue, 9 Dec 2025 16:17:36 -0500 Subject: [PATCH 1/4] docs(release): add release process guide for internal contributors --- CONTRIBUTING.md | 8 ++++ docs/internal/README.md | 3 ++ docs/internal/release-process.md | 64 ++++++++++++++++++++++++++++++++ 3 files changed, 75 insertions(+) create mode 100644 docs/internal/README.md create mode 100644 docs/internal/release-process.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ca77434505d..a622eaf573a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,6 +4,7 @@ - [Contributing to the Status App](#contributing-to-the-status-app) - [Table of Contents](#table-of-contents) - [🛠️ Developing](#️-developing) + - [Internal guides](#internal-guides) - [🪲 Status App Community Testing](#-status-app-community-testing) - [Disclaimer](#disclaimer) - [**🛠️ Testing Instructions for Status Release Candidate Build**](#️-testing-instructions-for-status-release-candidate-build) @@ -25,6 +26,13 @@ - Check out [good first issues](https://github.com/status-im/status-app/contribute) to get involved. - Join the [#feedback-desktop](https://status.app/cc/G-EAAORobqgnsUPSVCLaSJr855iXTIdQiY1Q0ckBe8dWWEBpUAs9s8DTjWEpvsmpE83Izx1JWQuZrWWKUoxiXCwdtB-wPBzyvv_n9a0F61xTaPZE7BEJDC7Ly_WcmQ4tHRAKnPfXE_JUtEX_3NhnXQN0eh4ue0D77dWvaDpDrSi0U0CaGLZ-pqD_iV0z9RMFE2LKulDZdwL40etJ8lxjyTFoxS0lUhdWKinIOk8qBmJJpCmsqMrSklEU#zQ3shZeEJqTC1xhGUjxuS4rtHSrhJ8vUYp64v6qWkLpvdy9L9) and [#feedback-mobile](https://status.app/cc/G-EAAOTgmsumqFvQZ-DSRkmf6xZuG-jQBrqnB6ytivISS1qeYURpfrzeMMePtpp7Inw_qy_cLdpZLJNUgOmfMHIZ4n2zSTr-n9u34C4yZa7c4JGLz9U6GIfjPqa0J0Ng2GC_Pu76QxgM-1v0z8V0PxxAf3fdHNbQXy-vfqWhK2iF0E6AaaJMh3sCmp_YpfFwR0DPmDIORPwdI_5ot4VZpkSb9FCkBwJO0xKNc5zI4oYpjfAhZVAyNWIHJs0D#zQ3shZeEJqTC1xhGUjxuS4rtHSrhJ8vUYp64v6qWkLpvdy9L9) channels on Status. +### Internal guides + +These guides are meant to be used by internal contributors. If you're an external contributor, you can also read them to get a sense of how we work, but you do not have to apply those guidelines. + +- [Release Process Guide](/docs/internal/release-process.md) +- Dev-Design-Product-QA Workflow (Comming soon) + ## 🪲 Status App Community Testing ### Disclaimer diff --git a/docs/internal/README.md b/docs/internal/README.md new file mode 100644 index 00000000000..420f11b9680 --- /dev/null +++ b/docs/internal/README.md @@ -0,0 +1,3 @@ +# Internal Guides + +This section is meant for internal contributors. Not because they are private, just because external contributors don't need to follow those guidelines. \ No newline at end of file diff --git a/docs/internal/release-process.md b/docs/internal/release-process.md new file mode 100644 index 00000000000..de2129d8b15 --- /dev/null +++ b/docs/internal/release-process.md @@ -0,0 +1,64 @@ +# Release Process Guide + +This guide is meant to explain the flow and rules of the release process, ie the period when we cut a release branch off the master branch in prevision of releasing it to users. Release Candidates (RC) are provided to test the Release. + +1. A release branch **must** be created at the start of the Release Process for the [Status App](https://github.com/status-im/status-app)'s master branch and [status-go](https://github.com/status-im/status-go)'s develop branch + 1. The format for the status-app branch is `release/MAJOR.MINOR.x`, eg. `release/2.36.x` + 2. The format for the status-go branch is automatically done using the Release script. Ask a status-go maintainer to create it. + 3. The status-app release branch **must** always point to the status-go release branch. + +2. Issues needing to be fixed on the RC **must** be added to the [Release Board](https://github.com/orgs/status-im/projects/97/views/1). + +3. Only bug fixes **must** be provided to the release branch. + +4. Moreover, only **critical** bug fixes **should** be added to the [Release Board](https://github.com/orgs/status-im/projects/97/views/1) and committed to the release branch. + 1. Critical bugs are issues that affect the **behaviour** of the features. + 2. This includes regressions to previously working features (eg: removing an emoji reaction no longer works). + 3. This also includes issues breaking new features, ie **not** according to the expected Acceptance Criteria (eg: Browser is expected to allow saving bookmarks and the feature does not work). + +5. One or more Testing days **should** be done by the entire Status team to find any regressions. + 1. The Status team **should** split in testing groups to help test features. + 2. Testing groups **should** contain people from different teams to spread the knowledge. + 3. Testing days **must** use a list of current features to test. + 4. The list **should** include a column listing issues found and by whom. + 5. The list **should** include an indicator whether that feature is covered by end-to-end (e2e) test and/or functional tests. + 6. The list **should** contain a section documenting which features were recently **added** or **refactored**. + 7. The recently added or refactored features **should** be the most tested. + 8. Features on the list **can** be tested by multiple testing groups. + +6. Regressions **should** be mentioned to the QA team so that they can plan and implement e2e tests to prevent further regressions of the sorts (to be implemented on master). + +7. Code coverage does **not** need to be met on the release branch. + +8. Features **must not** be allowed to be added to the release branch under any circumstances. + +9. Fixes for issues identified during the RC phase **must** be worked on and committed on the release branch **first**. + +10. Once a fix has been applied to the release branch, it **must** be ported to the master branch. + +11. A new RC build **can** be triggered every day, if there are new fixes in the release branch. + + +## Frequently asked questions + +### When is a release ready to be cut? + +A release is considered ready to be cut when all **Key** features are **Done**. + +A **Key** feature is a feature identified on the [Roadmap](https://github.com/status-im/status-app/blob/master/docs/roadmap.md) as the most important features for that release. + +A feature is considered **Done** when all issues of its Epic are closed. An Epic **must** include a testing issue, where one of the dev who worked on the issue meets with one of the designers and/or the Product Manager to demo the issue. Designers and/or the PM **should** open any issue they find on the new feature. + +#### What happens to the other features not ready at the time of the release cut? + +The remaining features listed on the [Roadmap](https://github.com/status-im/status-app/blob/master/docs/roadmap.md) on the same milestone, but that were not identified as **key**, will simply be pushed to the next milestone. + +All new features **must** implement a **feature flag**. Therefore, unfinished features **must not** affect master and the release. + +### Why commit to the release branch first and not master? + +1. It is faster for the release. +2. Less possibilities of conflicts on the release branch. +3. Cherry-picked commits are often **not** tested. That is acceptable on master, but **unacceptable** on the release branch. +4. Issues do **not** close as completed when merged on the release branch. Therefore, it is easy to spot that the commit needs to be cherry-picked to master. + From 8b4c18bc4967b854d45c8198f1d06d1f287fef67 Mon Sep 17 00:00:00 2001 From: Jonathan Rainville Date: Wed, 10 Dec 2025 13:35:47 -0500 Subject: [PATCH 2/4] docs(release): clarify who must cherry-pick --- docs/internal/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/internal/release-process.md b/docs/internal/release-process.md index de2129d8b15..37109e93c34 100644 --- a/docs/internal/release-process.md +++ b/docs/internal/release-process.md @@ -34,7 +34,7 @@ This guide is meant to explain the flow and rules of the release process, ie the 9. Fixes for issues identified during the RC phase **must** be worked on and committed on the release branch **first**. -10. Once a fix has been applied to the release branch, it **must** be ported to the master branch. +10. Once a fix has been applied to the release branch, it **must** be ported to the master branch by the author of the commit. 11. A new RC build **can** be triggered every day, if there are new fixes in the release branch. From 6af309f769eebe097f39a1aebcb0c51986987c76 Mon Sep 17 00:00:00 2001 From: Jonathan Rainville Date: Thu, 18 Dec 2025 15:59:52 -0500 Subject: [PATCH 3/4] docs(release): update critical bugs and how to version --- docs/internal/release-process.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/docs/internal/release-process.md b/docs/internal/release-process.md index 37109e93c34..6e7864d36d2 100644 --- a/docs/internal/release-process.md +++ b/docs/internal/release-process.md @@ -12,10 +12,11 @@ This guide is meant to explain the flow and rules of the release process, ie the 3. Only bug fixes **must** be provided to the release branch. 4. Moreover, only **critical** bug fixes **should** be added to the [Release Board](https://github.com/orgs/status-im/projects/97/views/1) and committed to the release branch. - 1. Critical bugs are issues that affect the **behaviour** of the features. - 2. This includes regressions to previously working features (eg: removing an emoji reaction no longer works). - 3. This also includes issues breaking new features, ie **not** according to the expected Acceptance Criteria (eg: Browser is expected to allow saving bookmarks and the feature does not work). - + 1. Critical bugs are issues that affect: + 1. security + 2. potential data or funds loss + 3. crashes + 4. full regressions 5. One or more Testing days **should** be done by the entire Status team to find any regressions. 1. The Status team **should** split in testing groups to help test features. 2. Testing groups **should** contain people from different teams to spread the knowledge. @@ -37,6 +38,10 @@ This guide is meant to explain the flow and rules of the release process, ie the 10. Once a fix has been applied to the release branch, it **must** be ported to the master branch by the author of the commit. 11. A new RC build **can** be triggered every day, if there are new fixes in the release branch. +12. Releases and RCs **must** have unique semantic numbers in the `VERSION` file and `tag`. + 1. Release format: `2.36.0` + 2. RC format: `2.36.0-rc.1` +13. The commit updating the `VERSION` file **must** have a `tag` matching the same version number on it. ## Frequently asked questions @@ -53,7 +58,7 @@ A feature is considered **Done** when all issues of its Epic are closed. An Epic The remaining features listed on the [Roadmap](https://github.com/status-im/status-app/blob/master/docs/roadmap.md) on the same milestone, but that were not identified as **key**, will simply be pushed to the next milestone. -All new features **must** implement a **feature flag**. Therefore, unfinished features **must not** affect master and the release. +All new features **must** implement a **feature flag**. Therefore, unfinished features **must not** affect negatively the master and release branches. ### Why commit to the release branch first and not master? From f9c1ddcfc0fe79b1d121bd1e066ebb8c3b974892 Mon Sep 17 00:00:00 2001 From: Jonathan Rainville Date: Thu, 15 Jan 2026 14:49:01 -0500 Subject: [PATCH 4/4] chore: fix typos --- CONTRIBUTING.md | 2 +- docs/internal/release-process.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a622eaf573a..68f7d383e44 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -31,7 +31,7 @@ These guides are meant to be used by internal contributors. If you're an external contributor, you can also read them to get a sense of how we work, but you do not have to apply those guidelines. - [Release Process Guide](/docs/internal/release-process.md) -- Dev-Design-Product-QA Workflow (Comming soon) +- Dev-Design-Product-QA Workflow (Coming soon) ## 🪲 Status App Community Testing diff --git a/docs/internal/release-process.md b/docs/internal/release-process.md index 6e7864d36d2..da8dfd5ab51 100644 --- a/docs/internal/release-process.md +++ b/docs/internal/release-process.md @@ -1,6 +1,6 @@ # Release Process Guide -This guide is meant to explain the flow and rules of the release process, ie the period when we cut a release branch off the master branch in prevision of releasing it to users. Release Candidates (RC) are provided to test the Release. +This guide is meant to explain the flow and rules of the release process, i.e. the period when we cut a release branch off the master branch in prevision of releasing it to users. Release Candidates (RC) are provided to test the Release. 1. A release branch **must** be created at the start of the Release Process for the [Status App](https://github.com/status-im/status-app)'s master branch and [status-go](https://github.com/status-im/status-go)'s develop branch 1. The format for the status-app branch is `release/MAJOR.MINOR.x`, eg. `release/2.36.x` @@ -17,7 +17,7 @@ This guide is meant to explain the flow and rules of the release process, ie the 2. potential data or funds loss 3. crashes 4. full regressions -5. One or more Testing days **should** be done by the entire Status team to find any regressions. +5. One or more testing days **should** be done by the entire Status team to find any regressions. 1. The Status team **should** split in testing groups to help test features. 2. Testing groups **should** contain people from different teams to spread the knowledge. 3. Testing days **must** use a list of current features to test. @@ -31,9 +31,9 @@ This guide is meant to explain the flow and rules of the release process, ie the 7. Code coverage does **not** need to be met on the release branch. -8. Features **must not** be allowed to be added to the release branch under any circumstances. +8. Features **must not** be allowed to be added to the release branch under any circumstances. -9. Fixes for issues identified during the RC phase **must** be worked on and committed on the release branch **first**. +9. Fixes for issues identified during the RC phase **must** be worked on and committed on the release branch **first**. 10. Once a fix has been applied to the release branch, it **must** be ported to the master branch by the author of the commit.