From 85382215f865d25e9e975b91d4a0298fa4abb8f6 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Mon, 30 Dec 2024 12:25:36 +0000 Subject: [PATCH 1/9] [docs] Document the release management principles Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 78 ++++++++++++++++++++++++++++++++------ 1 file changed, 67 insertions(+), 11 deletions(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index 227fb116e3..1fce8b8ba8 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -1,12 +1,70 @@ # Release Management -## Apple App Store +## Principles -### Upload metadata and screenshots to the App Store +The project management follows the **Fixed-Time, Variable-Scope** principle. This means that releases occur on a **predictable** schedule, while the scope of each release **may vary**. + +### Schedule + +Everyone should plan with the expectation that releases will happen predictably **every month**. + +The current objective is to perform 1 (one) **feature release** (containing new features) per month, with the target of uploading the App Store and Google Play versions for review by the first Monday of each month. + +In addition to the monthly feature release, a **data-only release** (containing only updated OSM data, with no new features) shall occur in the middle of the month, typically around the 15th. + +### Scope + +Everyone should expect that each release will include only what was finished on time and **not delayed by waiting** for anyone. + +The scope of the release **may vary** based on the readiness of the features. Volunteer Contributors work at their own pace. The funded work should adhere to the scope and schedule outlined in the agreed project plan, with guidance provided by the person in charge of the project (the Project Manager). + +### Schedule vs Scope + +Each release aims to include all features that have been merged into the master branch before the release cut-off date and have not caused regressions during the QA validation process. If certain changes are not included in the current release, they will be postponed to the next one. + +The general recommendation is to merge large changes immediately after the release to allow the entire month for fixing potential regressions and stabilizing the system. + +### Release Manager + +Each release has one person appointed as the Release Manager to oversee the execution of the release management process. + +It is the duy of Release Manager to drive the enture process to the successful completion, utilizing all available resources and means. Specific tasks may be delegated to individual team members as required. + +The person holds the authority to make final decisions on cut-off and release dates, and can exclude or revert changes to ensure the release schedule is met. + +### Collaboration + +Volunteer Contributors and Project Managers are encouraged to plan accordingly and communicate clearly with the Release Manager about their schedules, as well as any potential risks or regressions after merging each feature. + +### Scoping + +Each release should have a dedicated 20YY.MM milestone created on GitHub. Contributors and Project Managers are encouraged to use it for organizing their work. + +### Blockers + +Any regressions discovered must be filed as blocking bug tickets and added to the milestone with a clear and understandable description. Contributors are encouraged to proactively revert their changes if it is unrealistic to stabilize them before the cut-off date. + +### Tracking Ticket + +Each release progress is tracked using the Release Tracking Issue ticket on GitHub, which contains a checklist of items to be executed in the correct order. + +### Communication + +Any decision made must be documented in writing within the ticket, ensuring that the motivation and reasoning are clear and understandable to all. + +## Process + +TO BE DOCUMENTED HERE + +## Recipies + +Below is a list of useful snippets for any ad-hoc tasks that may arise during the execution of the process. + +### AppStore: uploading metadata and screenshots Use [GitHub Actions](../.github/workflows/ios-release.yaml). -### Check metadata +### AppStore: checking metadata Use [GitHub Actions](../.github/workflows/ios-check.yaml). @@ -16,7 +74,7 @@ Local check: ./tools/python/check_store_metadata.py ios ``` -### Downloading screenshots from the App Store +### AppStore: downloading screenshots Get xcode/keys/appstore.json - App Store API Key. @@ -36,23 +94,21 @@ cd xcode ./fastlane download_screenshots ``` -## Google Play - -### Upload metadata and screenshots to Google Play +### Google Play: uploading metadata and screenshots Use [GitHub Actions](../.github/workflows/android-release-metadata.yaml). -### Uploading a new version to Google Play +### Google Play: uploading a new version Use [GitHub Actions](../.github/workflows/android-release.yaml). Promote version to "Production" manually in Google Play Console. -### Uploading a new version to Huawei AppGallery +### Huawei AppGallery: uploading a new version Use [GitHub Actions](../.github/workflows/android-release.yaml). -### Checking metadata +### Google Play: checking metadata Use [GitHub Actions](../.github/workflows/android-check.yaml). @@ -62,7 +118,7 @@ Checking locally: ./tools/python/check_store_metadata.py android ``` -### Downloading metadata and screenshots from Google Play +### Google Play: downloading metadata and screenshots Get `android/google-play.json` - Google Play API Key. -- 2.45.3 From 421278920d8c3bcb88da65821318cc87493bb317 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Thu, 2 Jan 2025 11:33:13 +0000 Subject: [PATCH 2/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index 1fce8b8ba8..c572c7dff6 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -1,6 +1,6 @@ # Release Management -## Principles +## Guidelines The project management follows the **Fixed-Time, Variable-Scope** principle. This means that releases occur on a **predictable** schedule, while the scope of each release **may vary**. -- 2.45.3 From 650a9a334342304286fe9f4038e5ee13a94ee0c1 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Thu, 2 Jan 2025 11:33:21 +0000 Subject: [PATCH 3/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index c572c7dff6..26f2eb89b5 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -2,7 +2,7 @@ ## Guidelines -The project management follows the **Fixed-Time, Variable-Scope** principle. This means that releases occur on a **predictable** schedule, while the scope of each release **may vary**. +The release management follows the **Fixed-Time, Variable-Scope** principle. This means that releases occur on a **predictable** schedule, while the scope of each release **may vary**. ### Schedule -- 2.45.3 From 1ac9f4c7cac9a4dafeab5bd1575317b2a3297b03 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Thu, 2 Jan 2025 11:35:34 +0000 Subject: [PATCH 4/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index 26f2eb89b5..bb7c71ded0 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -26,7 +26,7 @@ The general recommendation is to merge large changes immediately after the relea ### Release Manager -Each release has one person appointed as the Release Manager to oversee the execution of the release management process. +Each release has one person appointed as the Release Manager to oversee the upcoming release. It is the duy of Release Manager to drive the enture process to the successful completion, utilizing all available resources and means. Specific tasks may be delegated to individual team members as required. -- 2.45.3 From 21b3b15502c8358242247d710f93768a96c47710 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Tue, 7 Jan 2025 20:25:29 +0000 Subject: [PATCH 5/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index bb7c71ded0..18053e1bfd 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -16,7 +16,7 @@ In addition to the monthly feature release, a **data-only release** (containing Everyone should expect that each release will include only what was finished on time and **not delayed by waiting** for anyone. -The scope of the release **may vary** based on the readiness of the features. Volunteer Contributors work at their own pace. The funded work should adhere to the scope and schedule outlined in the agreed project plan, with guidance provided by the person in charge of the project (the Project Manager). +Hence the scope of each release **may vary** based on the readiness of the features. Volunteer Contributors work at their own pace while the funded work adheres to the scope and schedule outlined in the agreed project plan. ### Schedule vs Scope -- 2.45.3 From dd11bd3097247d7a2b82129357e8dcda37af78c9 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Tue, 7 Jan 2025 20:25:38 +0000 Subject: [PATCH 6/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index 18053e1bfd..f011e9152b 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -28,7 +28,7 @@ The general recommendation is to merge large changes immediately after the relea Each release has one person appointed as the Release Manager to oversee the upcoming release. -It is the duy of Release Manager to drive the enture process to the successful completion, utilizing all available resources and means. Specific tasks may be delegated to individual team members as required. +It is the duty of the Release Manager to drive the entire process to the successful completion, utilizing all available resources and means. Specific tasks may be delegated to individual team members as required. The person holds the authority to make final decisions on cut-off and release dates, and can exclude or revert changes to ensure the release schedule is met. -- 2.45.3 From b047b8306eb6cc13bff0fc9404784d2ecc8eb512 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Tue, 7 Jan 2025 20:25:57 +0000 Subject: [PATCH 7/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index f011e9152b..d19510e4f6 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -30,7 +30,7 @@ Each release has one person appointed as the Release Manager to oversee the upco It is the duty of the Release Manager to drive the entire process to the successful completion, utilizing all available resources and means. Specific tasks may be delegated to individual team members as required. -The person holds the authority to make final decisions on cut-off and release dates, and can exclude or revert changes to ensure the release schedule is met. +The person holds the authority to make final decisions on cut-off and release dates, and can exclude or revert changes to ensure the release schedule and quality targets are met. ### Collaboration -- 2.45.3 From 7e6ebdd56a8dd89c168732a2490f3362eb03cfee Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Tue, 7 Jan 2025 20:26:15 +0000 Subject: [PATCH 8/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index d19510e4f6..afe47e49dd 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -14,7 +14,7 @@ In addition to the monthly feature release, a **data-only release** (containing ### Scope -Everyone should expect that each release will include only what was finished on time and **not delayed by waiting** for anyone. +Everyone should expect that each release will include only what was finished on time and **won't be delayed** to include any particular "almost ready" change (there could be exceptions for important hot fixes only). Hence the scope of each release **may vary** based on the readiness of the features. Volunteer Contributors work at their own pace while the funded work adheres to the scope and schedule outlined in the agreed project plan. -- 2.45.3 From 8a6615f17c39e12e98406c895663e3704d524870 Mon Sep 17 00:00:00 2001 From: Roman Tsisyk Date: Tue, 7 Jan 2025 20:26:37 +0000 Subject: [PATCH 9/9] Update docs/RELEASE_MANAGEMENT.md Co-authored-by: Konstantin Pastbin Signed-off-by: Roman Tsisyk --- docs/RELEASE_MANAGEMENT.md | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/docs/RELEASE_MANAGEMENT.md b/docs/RELEASE_MANAGEMENT.md index afe47e49dd..851fd33136 100644 --- a/docs/RELEASE_MANAGEMENT.md +++ b/docs/RELEASE_MANAGEMENT.md @@ -32,25 +32,15 @@ It is the duty of the Release Manager to drive the entire process to the success The person holds the authority to make final decisions on cut-off and release dates, and can exclude or revert changes to ensure the release schedule and quality targets are met. -### Collaboration +### Release Tracking -Volunteer Contributors and Project Managers are encouraged to plan accordingly and communicate clearly with the Release Manager about their schedules, as well as any potential risks or regressions after merging each feature. +Each release should have its own Release Tracking Issue on GitHub, which contains a schedule and a checklist of items to be executed in the correct order. -### Scoping - -Each release should have a dedicated 20YY.MM milestone created on GitHub. Contributors and Project Managers are encouraged to use it for organizing their work. - -### Blockers +Also each release should have a dedicated 20YY.MM github milestone. All contributors are encouraged to use it for organizing their work and to communicate clearly with the Release Manager about their schedules, as well as any potential risks or regressions after merging each feature. Any regressions discovered must be filed as blocking bug tickets and added to the milestone with a clear and understandable description. Contributors are encouraged to proactively revert their changes if it is unrealistic to stabilize them before the cut-off date. -### Tracking Ticket - -Each release progress is tracked using the Release Tracking Issue ticket on GitHub, which contains a checklist of items to be executed in the correct order. - -### Communication - -Any decision made must be documented in writing within the ticket, ensuring that the motivation and reasoning are clear and understandable to all. +Any decision made must be documented in writing within the Release Tracking Issue, ensuring that the motivation and reasoning are clear and understandable to all. ## Process -- 2.45.3