Decide how to align GitLab versions with Operator versions

Summary

The GitLab OpenShift Operator will eventually be versioned. Each version of the operator will likely support several versions of GitLab so that an end user can use the Operator to upgrade their GitLab instance. We need to decide on a strategy for which/how many versions need to be supported in an Operator version.

Questions

1. What are some examples of changes that would require a new version of the Operator to be released?
2. If the Operator consumes the GitLab Helm chart, does this issue need to address GitLab versions or Helm chart versions?
3. How much overlap do we need to have? For example:
   • Operator 1.0 supports GitLab 12.10, GitLab 13.0, GitLab 13.1
   • Operator 1.1 supports GitLab 13.1, GitLab 13.2, GitLab 13.3
4. What is our user upgrade behaviour? Do they often skip over a lot of versions when they do an upgrade?
5. For zero downtime upgrades, a user needs to upgrade one minor release at a time for Omnibus installs. What is our zero downtime upgrade story for Helm installs?

Factors to consider

• Official GitLab support covers the three most recent minor versions of GitLab
• One major version of GitLab is released per year. Major Helm chart versions don't align with major GitLab versions
  • The reasoning: rapid changes within Kubernetes & surrounding ecosystem. We need to be capable of making major changes without waiting most of a calendar year.
• Users need to upgrade to the last minor version before upgrading to the next major version.
• Upgrade paths are documented here.

Proposal

TBD based on the discussion above.