Practise the standard verbs for writing deprecation notices consumers can actually act on.
0 / 5 completed
1 / 5
Fill in: 'We ___ a concrete removal date in every deprecation notice, so a consumer isn't left guessing whether the old behaviour has months or only days left.'
We 'state a date' — the standard, simple collocation for giving a firm timeline in a deprecation notice. The other options are less idiomatic here.
2 / 5
Fill in: 'Publishing a vague deprecation warning with no removal date attached can ___ a consumer treating the old behaviour as safe to keep relying on indefinitely.'
We say a vague warning will 'leave' the old behaviour treated as safe — the standard, natural collocation for the resulting complacency. The other options aren't idiomatic here.
3 / 5
Fill in: 'We ___ a clear migration path alongside every deprecation notice, since telling a consumer something is going away without saying what to use instead just creates friction.'
We 'provide a path' — the standard, simple collocation for offering a concrete alternative alongside a deprecation. The other options are less idiomatic here.
4 / 5
Fill in: 'We ___ a runtime warning to the deprecated code path itself, so a consumer discovers the notice from their own logs, not only from a changelog they may never read.'
We 'attach a warning' — the standard, simple collocation for embedding a deprecation signal directly in running code. The other options are less idiomatic here.
5 / 5
Fill in: 'We ___ actual usage of a deprecated feature before removing it on schedule, since a surprising amount of live traffic still hitting it changes the real timeline.'
We 'check usage' — the standard, simple collocation for confirming real-world reliance before finalising a removal. The other options aren't idiomatic here.