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..6e7864d36d2 --- /dev/null +++ b/docs/internal/release-process.md @@ -0,0 +1,69 @@ +# 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: + 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. + 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 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 + +### 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 negatively the master and release branches. + +### 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. +