GitLab should push breaking changes that have missed the 16.0 window to 17.0
Context
GitLab manages releases in accordance with semantic versioning s laid out in the docs. The 16.0 milestone was a short milestone to include changes and particularly breaking changes due to the major release landing on a Monday. This was broadly communicated across slack channels and with internal issues
- 16.0 - Assess Breaking Changes Impact & Plan fo... (#5541 - closed)
- Coordinate 16.0 major release rollout on GitLab... (gitlab-com/gl-infra&924 - closed)
- 16.0 Release Preparation - What to expect (gitlab-com/gl-infra/delivery#2924 - closed)
- 16.0 Breaking Changes - Request for additional ... (#5673 - closed)
The candidate release was tagged on 2023-05-17 and as a result, some features planned for 16.0 have missed the cutoff date and cannot be included in the 16.0 release. This is also true for a number of breaking changes. Message confirming the RC available at https://gitlab.slack.com/archives/C0XM5UU6B/p1684349600751839
GitLab Chatops
:mega: The stable branch has been created and the release candidate is tagged. Barring any show-stopping issues, this is the final commit to be released on the 22nd.
https://gitlab.com/gitlab-org/security/gitlab/-/commits/16-0-stable-ee
You can check if an MR made the cut by using the following ChatOps command: /chatops run release check [MR_URL] 16.0
* Documentation about release check chatops command: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/deploy/auto-deploy.md#status-of-a-merged-mr-with-respect-to-monthly-releases
Problem
Based on the discovery I am doing as part of GitLab Releases and Maintenance policies (gitlab-com/gl-infra&988) and specifically in https://gitlab.com/gitlab-org/ux-research/-/issues/2434#note_1392536584 , there is significant customer frustration around breaking changes and our lack of consistency in applying our breaking change policy and the negative results it creates for customers as a result.
This is particularly painful for customers on gitlab.com, who are at the mercy of breaking changes at any time. However this will also increase the difficulty of upgrade for customers into 16.x if there are many breaking changes introduced into 16.1 - 16.3 due to missed milestones.
Proposal
Based on the feedback from customers in https://gitlab.com/gitlab-org/ux-research/-/issues/2434+ and the number of breaking changes that have missed the 16.0 window, GitLab should mandate that we are strict with our breaking change policy and all but the highest severity/impact breaking changes are delayed until 17.0.
Non-exhaustive list of breaking changes that missed 16.0 (or have their milestone set to 16.1)
- Feature Flag Rollout: Breaking change in Deploy... (gitlab-org/gitlab#409584 - closed)
- Remove Embed Grafana panels in Markdown (gitlab-org/gitlab#389477 - closed)
- Remove DAST_API_HOST_OVERRIDE and DAST_API_SPEC... (gitlab-org/gitlab#383467 - closed)
- Deprecate support for License Compliance CI Tem... (gitlab-org/gitlab#387561 - closed)
- https://gitlab.com/gitlab-org/gitlab/-/issues/382159+ (https://gitlab.slack.com/archives/CCFV016SV/p1684468162018059?thread_ts=1684411831.915839&cid=CCFV016SV)
- Removal of Jira Cloud DVCS Support (gitlab-org&7508 - closed)
- API Deprecation documentation of confidential n... (gitlab-org/gitlab#371485 - closed)
16.3 or higher
/cc @fzimmer @marin @amyphillips @mbursi