Breaking Changes

This page tracks our approach to Breaking Changes towards our users, whether via the website or the API.

Things that would count as a breaking change:

1. A change in product itself. If a page was tracking X, but it will track Y instead.
2. A split or merge in the product page(s).
3. Release Cycle Format changes. Such as a product switching from x.y to merely x
4. The definition of a given field changing (such as lts or eol), including custom column definition.
5. Page deletions
6. Update of the permalink, even if a redirection is set up (it breaks CORS when using the API).

A few examples of what would not count as a breaking change (non-exhaustive):

1. Major changes in the underlying product support policy itself.
2. License changes in the product.
3. Regular correction of EOL dates or other data, such as release dates, even if it might be drastic (such as a typo from 2005 -> 2025.
4. Regular compaction of release cycles, such as if a product only supports the latest minor release and older minor releases are compacted to a single major release. While this reduces the visibility of a release, the information on the page remains exactly the same.
5. Changes in lts field usage.

How to deal with breaking changes

This is primarily for maintainers:

1. Tag any such change PR or Issue with the label Breaking Change. We already do this in most cases, but having a clear framework (see above) will be helpful to take these calls.
2. Announce such changes (Ideally automatic RSS feed, and an automated github issue so we don't have to do it).
3. Wait 7 days before merging any such changes, ideally with some automation (such as keeping such PRs as failing in final step till the 7 day timer is up). 7 days is the minimum, but we should be open to extending it if the community will be helped by it.
4. Put a banner on the impacted page about the upcoming breaking change (automated as well?)