Breaking changes are important information for every DevSecOps team. We want to ensure that breaking changes for GitLab’s DevSecOps Platform are conveyed in a single source of truth (SSoT). Therefore, we are discontinuing the breaking changes blog post that accompanies GitLab major releases as it is a duplication of our SSoT. In its place, the Deprecations page in the documentation will act as the SSoT for all breaking changes, deprecations, and removals.
The Deprecations page holds the most up-to-date information for GitLab users, so please add it to your bookmarks.
Minimizing breaking changes
We understand the disruption that breaking changes can have on workflows, so we only include breaking changes in our major releases in line with our semantic versioning policy, with a few exceptions.
We also try to minimize the number of breaking changes that we introduce. However, sometimes they are needed to improve workflows, performance, scalability, and more. For example, if we ascertain that existing features are not as valuable or intuitive as they should be – and that developers aren’t using them as a result – then we may choose to deprecate or remove those features in favor of something that is more useful and easy to adopt. Similarly, critical issues or changes to supporting infrastructure and services can lead to breaking changes and we do our best to minimize the impact to users. You can find more information on how we deprecate GitLab features in our docs.
The Deprecations page lists all planned removals in GitLab 16.0.
Updates to Deprecations page
The Deprecations page has a few new features! You can now:
- filter by the removal version
- toggle only breaking changes
These features enable you to examine exactly what deprecations, removals, and breaking changes are planned for each version of GitLab as well as filter out non-breaking changes.
Following the release of 15.11 on April 22, we will have a number of breaking changes that will flow into gitlab.com. We understand the impact that breaking changes can have on gitlab.com customers and we are working on additional communication to ensure minimal, if any, disruption.
How to use the Deprecations page
By default, the Deprecations page shows all planned removals for GitLab.
You can filter for a specific removal version by using the dropdown and selecting the version you want to inspect.
Next to the removal dropdown, there is a toggle for breaking changes. Setting this toggle to the active position will filter the results on the page so that only breaking changes are displayed.
Iterating breaking changes communication
We’re continuously iterating toward a better product and that includes how we communicate with our users. The updates to the Deprecations page make it easier to get the most up-to-date information on breaking changes landing on gitlab.com. In our upcoming iteration, we plan to make the data even more granular to match the pace of our continuous delivery process.
If you need to see all changes in gitlab.com, not just breaking changes, deprecations, and removals, our Customer Success team has a dashboard that we’ve shared with our community. Here you can see the latest issues and MRs for features that have made it into gitlab.com.
We welcome your feedback
At GitLab, we are public by default and we want to collaborate with you on what comes next. If you have ideas for iterating our deprecations page or if you encounter a bug, please comment on our feedback issue, or reach out to our team and let us know.
