Pilot: Use the DEPR process for breaking changes

[kdmccormick]

Maintenance WG is trying out a new way of using the DEPR process. We'll takes notes here. If it goes well, then we will update the DEPR OEP accordingly. The problem we're trying to solve that we don't want to increase the number of channels that an operator has to follow to find out about removal, breaking changes or operational impact of changes. We'll consider this experiment a success if we can manage the next few upcoming maintenance items with breaking changes without significantly having to contort the DEPR process to make this work.

Here's the idea:

• All breaking changes warrant a DEPR ticket. Not only feature removals, but also upgrades and public API changes.
• All consumers of edx-platform should have a 6 month window to handle breaking changes, including both folks using named releases and folks using main.
• When possible, we should think of breaking changes in terms of expand/react/contract
• When a DEPR is communicated, it should include the following:
  • Communication Date (beginning of comment period)
  • Acceptance Date (~2 weeks from Communication)
  • Target date+release for "expand", ie replacement availability (if applicable).
  • In the case of an upgrade (e.g. Node 18), the replacement is the new version (e.g. Node 20)
  • In the case of an API breakage, the replacement would be the new/updated API.
  • In the case of a total removal, there is no "expand" moment, so the 6 month timer starts at Acceptance.
    • Q: Should total removals have a longer comment period?
  • Target date+release for "contract", ie removal of the deprecated thing
  • The "react" window (the time between "expand" and "contract") is 6 months by default
  • We want to have a way of easily seeing all the tickets in this state. This is essentially a To Do list for operators, especially operators working off of main.
• DEPRs ticket should remain oriented around removals/breakages. For example, we wouldn't make a DEPR ticket for "Adding Python 3.12 support", but we would have a DEPR ticket for "Dropping Python 3.11 support"

[kdmccormick]

@robrap @feanil That is my quick writeup on what we're doing, feel free to edit it or add your own notes.

[robrap]

Thanks @kdmccormick. This is great. We also mentioned that we plan to expose some of the dates as metadata on the DEPR board so organizations can easily see by when they need to handle the different states.

[sarina]

Happy to see this evolving, I will silently keep tabs and happy to help with the OEP authoring/reviewing if this experiment succeeds.

I'd love to see a quick sentence or two in the description about (a) what problem this is trying to solve, and (b) what "success" of the experiment is.