Automation for tracking breaking changes #14785
Conversation
…mentation into breaking-automation
|
great feature! A little bit too much magic with bash and perl where a python script against the gh API would probably also work - but I don't expect we'll have to change that often. |
@trask I was originally thinking we'd use this label for both scenarios, since when we finally remove deprecated features it would likely be considered a "breaking change", but thinking through it more, it would be good to be able to distinguish the "first" stage of just marking something as deprecated, and highligting that, and then when it's actually removed, use the "breaking change" label. I'll update this PR to include that flow as well |
| When your PR deprecates functionality: | ||
|
|
||
| * Add the `deprecation` label to your PR | ||
| * Provide deprecation details in the PR description: | ||
| - What is being deprecated and why | ||
| - What should be used instead (if applicable) | ||
| - Timeline for removal (if known) | ||
| - Any migration guidance |
There was a problem hiding this comment.
Not directly related to this PR, but I wonder how we would apply this in practice, for examples with the changes we plan for 3.0 like metrics semconv stability.
- we usually introduce a config option, where the default is to keep current behavior before 3.0
- when the next major happens, we switch the default of the config option and remove the config option, which is effectively a breaking change.
The second step should be labelled with breaking change.
However, should the 1st step be labelled as deprecation because we introduce a config option that we know will be removed in the future ? Or do we need to plan a separate deprecation process to review config options between introducing the new config option and removing it ? The downside of doing this in a separate step is that it would be easy to miss something.
There was a problem hiding this comment.
Or do we need to plan a separate deprecation process to review config options between introducing the new config option and removing it
it does feel a bit different from the standard approach, i guess i just assumed 3.0 would be the breaking change, and we'd provide a new config for them to revert back if they wanted.
Not directly related to this PR
i do think it would be great for us to figure this out and include that in this documentation, I don't think we currently have any official docs on deprecation strategies in this repo
|
|
||
| When your PR introduces a breaking change: | ||
|
|
||
| * Add the `breaking change` label to your PR |
There was a problem hiding this comment.
most contributors can't add labels to their PRs
There was a problem hiding this comment.
i've added some comment automation for this
4 participants
Resolves #9016
Introduces some automation via 2 labels that will leave a comment on the PRs instructing the authors to provide relevant documentation, and then when we prepare the changelog, the script will identify these PRs and list them in their appropriate sections.
The new labels are
breaking changeanddeprecationTested some of it on my fork: