Skip to content

Latest commit

 

History

History
22 lines (16 loc) · 1.05 KB

deprecation_policy.md

File metadata and controls

22 lines (16 loc) · 1.05 KB
Raw

Deprecation policy

The ability to deprecate features, components and paradigms is essential to the health of this project.

However, the price paid in disruption and maintenance is real; deprecating without warning, too often, or for poor rationale is a hinderance to adoption and contribution. It must be done with care and process.

Before embarking on the deprecation of any API we should collaboratively answer the following questions:

  1. Should this code be deprecated? Is the effort required to deprecate this component worth the benefit of removing the old behavior?
  2. Why is the code being deprecated? Why should clients switch?
  3. What are clients supposed to replace the code with?
  4. What is a good deprecation timeline?
  5. Who is responsible for the deprecation plan?

Deprecation process

If you would like to propose that an API be deprecated please file a bug explaining which API you'd like deprecated. Googlers can read more at go/material-ios-deprecation-process