GitLab 16.0 won't be a required stop on the upgrade path for self-managed customers

Problem to solve

Previous major releases (example: 12.0, 13.0, 14.0) had technical reasons for being required stops on the upgrade path.

Currently, 16.0 has no technical reason for being an upgrade stop. Upgrades, particularly large scaled out environments, are a lot of work for self managed customers, and so we are seeking to avoid any upgrade stop where possible.

Consecutive upgrade stops are painful because if the customer is trying to upgrade past a lot of releases, the extra stop adds a lot of work without as much perceived progress on the upgrade path.

The intent that 16.0 will not be an upgrade stop will be shared in other places, and this issue will be used for discussion etc.

Further details

Consequences:

• It cannot be assumed in 16.1 that a change made in 16.0 has been implemented. For example, a database change introduced in 16.0.
  • On customer instances, 16.0 and 16.1+ code and migrations will land at the same time.
• An example valid upgrade path for self managed customers could be: 15.4 > 15.11 > 16.2*
  • *The first upgrade stop in 16.x has yet to be determined.
• If there are any issues upgrading from 15.11 to 16.x that need workarounds, changes etc., these might be needed for later 16.x versions, since customers will be skipping it.
  • On the other hand, if those issues were fixed in later releases, customers will be able to skip to a version with the fix.

Proposal

• advertise in #backend
• advertise in #database
• advertise in engineering week in review
• advertise in support week in review
• advertise in #support_self-managed
• advertise in engineering-fyi
• advertise in DB maintainers channel
• Once 16.1 is released, the upgrade path docs might need make it clear that 16.0 is not an upgrade stop, since customers may assume it is one.

Who can address the issue

Other links/references