diff options
Diffstat (limited to 'doc/development/ruby_upgrade.md')
| -rw-r--r-- | doc/development/ruby_upgrade.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/development/ruby_upgrade.md b/doc/development/ruby_upgrade.md index 064cb8daf98..2102a256645 100644 --- a/doc/development/ruby_upgrade.md +++ b/doc/development/ruby_upgrade.md @@ -190,7 +190,7 @@ via `gdk update`. This pause is a good time to assess the risk of this upgrade for GitLab SaaS. For Ruby upgrades that are high risk, such as major version upgrades, it is recommended to coordinate the changes with the infrastructure team through a [change management request](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/). -Create this issue early to give everyone enough time to schedule and prepare changes. +Create this issue early to give everyone enough time to schedule and prepare changes. ### Make it the default Ruby @@ -205,7 +205,7 @@ in that repository. This change is only necessary when the minor or major versio ([example](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/merge_requests/176).) As mentioned above, if the impact of the Ruby upgrade on SaaS availability is uncertain, it is -prudent to skip this step until you have verified that it runs smootly in production via a staged +prudent to skip this step until you have verified that it runs smoothly in production via a staged rollout. In this case, go to the next step first, and then, after the verification period has passed, promote the new Ruby to be the new default. |