Added announcement of scheduled upgrades stops

What does this MR do and why?

Describe in detail what your merge request does and why.

Change

Scheduling required upgrade stops vs introducing upgrade stops ad-hoc with no notice to improve user experience and upgrade rate.

Key Takeaways

Required upgrade stops cause less self-managed users to be on the latest version of GitLab, which means less users seeing the latest features. Scheduling upgrade stops might delay some development velocity, but greatly improve user experience with self-managed GitLab.

Upgrade stops are introduced for a minimal amount of features, so this change would largely not impact the way features get released to self-managed or .com. It would impact a tiny percentage of changes in the grand scheme of our features we release.

Background

Required upgrade stops are versions that users must upgrade to and finalize before moving to later versions of GitLab. This version path shows what versions of GitLab, where users must stop. Required stops are introduced because changes require migrations to be finalized before moving to the next version or else a timeout will occur or the upgrade will fail due to an error.

Problem

Required upgrade stops are a major pain point for self-managed customers because many customers skip multiple versions as once when upgrading, and some organizations have a set amount of available downtime they are allowed to have in a quarter or year. So companies might only be able to upgrade once a quarter. Additionally, if a required stop is added with little notice or in sequence, this might leave some instances very far behind without the ability to easily skip ahead and catch up.

Proliferation of upgrade stops means GitLab is becoming increasingly complex to upgrade easily and choose convenient upgrade paths.

Past research on how easy it is to upgrade GitLab showed most users choose to upgrade based on keeping up with security. Adding more upgrade stops decreases the ease of staying up to date with our 3 milestone policy for security patches.

Some organizations are allowed a certain amount of downtime per quarter or year, so adding additional required stops means these organizations are unable to skip to the most up to date version of GitLab when they choose to set aside downtime. This is further complicated when these stops are announced with short notice.

A key indicator for predicting why customers are on the latest 3 versions were the number of users on an instance. This could indicate that instances related to organizations with less employees do not have the skills or the time or easily manage upgrades, so any additional upgrade complexity would cause these instances to have difficulty with required upgrade stops.

Product Impact

Scheduling required upgrade stops might delay some features being introduced to self-managed if the migration does not align with a scheduled stop. This would be delaying feature roll out for a milestone and could hold up some work. However, overall this will improve our upgrade rate so more users will see new features more quickly in their self-managed instance.

GitLab releases hundreds of new features a year and only a small number 8-10 end up requiring upgrade stops. The impact to releasing new features will be very small. Additionally, this might not affect new features being released to .com first at all. Our SaaS First principle is in place to ensure features are released before or at the same time as our self-managed offering, so this would not impact this principle if we introduce feature flags for features requiring upgrade stops.

Related issue on scheduled required upgrades - #358417 (closed)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.