From 0376a43b73a412f02e2fc3473b03ded39a7999f8 Mon Sep 17 00:00:00 2001 From: Alysia Broddrick Date: Sun, 7 Jan 2024 19:47:45 -0800 Subject: [PATCH 1/2] updated release cadence doc --- docs/operations/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/operations/README.md b/docs/operations/README.md index 0629608dd..9a4e6e2b8 100644 --- a/docs/operations/README.md +++ b/docs/operations/README.md @@ -45,7 +45,7 @@ Your sandbox space should've been setup as part of the onboarding process. If th ## Stable and Staging Release Rules -Releases will be made for staging and stable every week starting on the first day of the sprint (Wednesday), with the second release of the sprint occuring halfway through the sprint. With the exception of first time going into production, these releases will NOT have the same code. The release to stable will be the same commit that was tagged for staging one week prior, making stable one week behind staging. Further, this means staging can be up to a week behind the main branch of code. +Releases will be made for staging and stable twice a week, ideally Tuesday and Thursday, but can be adjusted if needed. Code on `main` will be released to `staging`, and then on the following Tuesday/Thursday this `staging` release will become the new `stable` release. This means every release day, a release will be made to `stable` containing the last `staging` code. On this same day a new `staging` release will be made that contains the most up-to-date code on main. Thus, `staging` can be a few days behind the main branch, and `stable` will be a few days behind the code on `staging`. If a bug fix or feature needs to be made to stable out of the normal cycle, this can only be done at the product owner's request. From 5f1f91e475c7b6c123ddae4341bc0a6c207ae3b5 Mon Sep 17 00:00:00 2001 From: Alysia Broddrick <109625347+abroddrick@users.noreply.github.com> Date: Tue, 9 Jan 2024 19:42:59 -0800 Subject: [PATCH 2/2] Update docs/operations/README.md Co-authored-by: zandercymatics <141044360+zandercymatics@users.noreply.github.com> --- docs/operations/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/operations/README.md b/docs/operations/README.md index 9a4e6e2b8..3fc43be50 100644 --- a/docs/operations/README.md +++ b/docs/operations/README.md @@ -45,7 +45,7 @@ Your sandbox space should've been setup as part of the onboarding process. If th ## Stable and Staging Release Rules -Releases will be made for staging and stable twice a week, ideally Tuesday and Thursday, but can be adjusted if needed. Code on `main` will be released to `staging`, and then on the following Tuesday/Thursday this `staging` release will become the new `stable` release. This means every release day, a release will be made to `stable` containing the last `staging` code. On this same day a new `staging` release will be made that contains the most up-to-date code on main. Thus, `staging` can be a few days behind the main branch, and `stable` will be a few days behind the code on `staging`. +Releases will be made for staging and stable twice a week, ideally Tuesday and Thursday, but can be adjusted if needed. Code on `main` will be released to `staging`, and then on the following Tuesday/Thursday this `staging` release will become the new `stable` release. This means every release day, a release will be made to `stable` containing the last `staging` code. On this same day a new `staging` release will be made that contains the most up-to-date code on main. Thus, `staging` can be a few days behind the main branch, and `stable` will be a few days behind the code on `staging`. If a bug fix or feature needs to be made to stable out of the normal cycle, this can only be done at the product owner's request.