Scheduled required paths for GitLab upgrades to improve UX
Overview
We currently require certain milestones as upgrade paths in order to do large migrations to implement feature work in the product.
This can cause a poor UX for users working in organizations that are allocated a certain amount of downtime per quarter/year.
Proposal
We should schedule required upgrade paths rather than have them implemented as needed. This would give users a schedule for expected downtime, and something that can be planned for in the future with consistency.
We should have required upgrade paths only be implemented at a midway point in the major release (X.5/6) and before the major release (X.10/11). Or add two upgrade stops 16.4 and 16.8 (then 16.11 by default) reducing the amount of time potential features would be delayed.
Impact/Discussion
-
This is likely to improve UX, however can have negative implication on feature development progress for teams. In order to mitigate this engineering teams would need to schedule the implementation of these large changes requiring upgrade paths for when the scheduled upgrade path is set.
-
We would need to gather previous research or conduct new research to see how much of an impact this might have on UX. We have done previous research on upgrade rate, but not specific to required upgrades. This information would be good to have when weighing it against the engineering impact.