Skip to content

Commit 8cfbee7

Browse files
Add deprecation checklist document for Substrate (#1583)
fixes #182 This PR adds a document with recommendations of how deprecations should be handled. Initiated within FRAME, this checklist could be extended to the rest of the repo. I want to quote here a comment from @kianenigma that summarizes the spirit of this new document: > I would see it as a guideline of "what an extensive deprecation process looks like". As the author of a PR, you should match this against your "common sense" and see if it is needed or not. Someone else can nudge you to "hey, this is an important PR, you should go through the deprecation process". > > For some trivial things, all the steps might be an overkill. --------- Co-authored-by: Francisco Aguirre <[email protected]>
1 parent d512b3f commit 8cfbee7

File tree

1 file changed

+79
-0
lines changed

1 file changed

+79
-0
lines changed

docs/DEPRECATION_CHECKLIST.md

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
# Deprecation Checklist
2+
3+
This deprecation checklist makes sense while we don’t use [SemVer](https://semver.org/).
4+
After that, this document will most likely change.
5+
As deprecation and removal of existing code can happen on any release, we need to be mindful that external builders
6+
could be impacted by the changes we make.
7+
The deprecation checklist tries to mitigate this impact, while still keeping the developer experience, the DevEx, as
8+
smooth as possible.
9+
10+
To start a deprecation process, a new issue with the label `T15-deprecation` needs to be created for correct tracking.
11+
Then these are the actions to take:
12+
13+
## Hard deprecate by adding a warning message
14+
15+
The warning message shall include a removal month and year, which is suggested to be 6 months after the deprecation
16+
notice is released.
17+
This means that the code will be removed in a release within that month (or after, but never before). Please use this
18+
template, doing so makes it easy to search through the code base:
19+
20+
```rust
21+
#[deprecated(note = "[DEPRECATED] will be removed after [DATE]. [ALTERNATIVE]")]
22+
```
23+
`[ALTERNATIVE]` won't always be possible but offer it if it is.
24+
25+
E.g.
26+
```rust
27+
#[deprecated(note = "`GenesisConfig` will be removed after December 2023. Use `RuntimeGenesisConfig` instead.")]
28+
```
29+
30+
Some pieces of code cannot be labeled as deprecated, like [reexports](https://github.com/rust-lang/rust/issues/30827)
31+
or [dispatchables](https://github.com/paritytech/polkadot-sdk/issues/182#issuecomment-1691684159), for instance.
32+
In cases like that we can only make a visible enough comment, and make sure that we [announce the deprecation properly](#announce-the-deprecation-and-removal).
33+
34+
## Remove usage of the deprecated code in the code base
35+
36+
Just make sure that we are not using the deprecated code ourselves.
37+
If you added the deprecation warning from the previous step, this can be done by making sure that warning is not shown
38+
when building the code.
39+
40+
## Update examples and tutorials
41+
42+
Make sure that the rust docs are updated.
43+
We also need [https://docs.substrate.io/](https://docs.substrate.io/) to be updated accordingly. The repo behind it is
44+
[https://github.com/substrate-developer-hub/substrate-docs](https://github.com/substrate-developer-hub/substrate-docs).
45+
46+
## Announce the deprecation and removal
47+
48+
**At minimum they should be noted in the release log.** Please see how to document a PR [here](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md#documentation).
49+
There you can give instructions based on the audience and tell them what they need to do to upgrade the code.
50+
51+
Some breaking changes have a bigger impact than others. When the impact is big the release note is not enough, though
52+
it should still be the primary place for the notice. You can link back to the changelog files in other channels if you
53+
want to announce it somewhere else.
54+
Make sure you are as loud as you need to be for the magnitude of the breaking change.
55+
56+
## Removal version is planned
57+
58+
Depending on the removal date indicated in the deprecation warning in the [first step](#hard-deprecate-by-adding-a-warning-message),
59+
the nature and the importance of the change, it might make sense to coordinate the release with other developers and
60+
with the Release team.
61+
62+
## Deprecated code is removed
63+
64+
The deprecated code finally gets removed.
65+
Don’t forget to [announce this accordingly](#announce-the-deprecation-and-removal).
66+
67+
✅ In order to not forget any of these steps, consider using this template in your deprecation issue:
68+
69+
```markdown
70+
### Tasks
71+
72+
- [ ] Deprecate code by adding a warning message
73+
- [ ] Remove usage of the deprecated code in the code base
74+
- [ ] Update examples and tutorials
75+
- [ ] Announce code deprecation
76+
- [ ] Plan removal version
77+
- [ ] Announce code removal
78+
- [ ] Remove deprecated code
79+
```

0 commit comments

Comments
 (0)