Define and add Breaking Changes communication process for 15.0 onward

Overview

In 13.0 and 14.0, we published and populated a breaking changes post as a supplement to the standard release post. We linked to the breaking changes post in the release post and in various channels including the broadcast message feature for SaaS.

The problem

This process was very manual and messy because we did not have a single SSOT for deprecations, removals or breaking changes. We need to define and add this process to the release post-process to allow PMs and release post managers to publish breaking changes posts for major releases without all the manual, an error-prone work.

The solution

Since we're planning to have one SSOT in Docs for both deprecations and removals, with clear flags for breaking changes, we will not do a unique breaking changes blog. The release post page and any messaging will point to the SSOT Docs page. Then, starting 3 cycles prior and up to 2 cycles after the major release, we'll use broadcast message feature for SaaS and What's New feature for Self-managed, to inform users of breaking changes.

To be determined:

  • we may still opt to do a one-time publication of all the removals in 15.0 release post, though it'll be a duplicate of what's in Docs, for extra due diligence
  • we may still opt to do a breaking changes blog for PR and other reasons (such as having something that can easily be translated to other languages for reference) but will auto-generate it from Docs SSOT to streamline efforts

Reference issues and MRs from 14.0

From 13.0:

Edited by Farnoosh Seifoddini