Good Deprecation Habits
- Determine a thing needs deprecation and (discuss w/ knowledgable parties if applicable).
- How long it must remain deprecated before it is removed is an important factor driven by the context involved.
- If used in new code it should barf w/ information:
- what is deprecated
- if applicable: why it was deprecated (or pointer to more info about the deprecation)
- when it was deprecated
- when it will be removed
- what case is tracking the removal
- case should have a due date and details of what needs removed/updated (including documentation)
- ensure that the case is followed through on at the given date
- what to use instead
- if applicable how to go ahead and use the deprecated thing
- Ideally, when changing the thing to be deprecated, you also remove all use of it from all code you control.
- if applicable: if used in existing code: allow it to run but give the info in item 2 as a warning
- if applicable: send out notices to appropriate audiences w/ info in item 2 about it being deprecated and again when it is removed
- if applicable: The changelog should include clearly tagged deprecation and removal info (e.g. the “Keep a Changelog” format has a nice mechanism for that)
- if applicable: map old systems to new (e.g. in a REST app a 301 could get them to the new route)