A lint begins its life as a proposal which is pending until accepted.
After discussion and sufficient agreement within the team, a proposed lint becomes accepted.
An accepted lint is ready for implementation.
Lints can be marked experimental.
Reasons a lint might be marked experimental include a lint
Stable lints are lints whose semantics and implementation are considered complete. False positives (that are not known, accepted and documentted limitations of lint semantics) are considered bugs and fixing them should be prioritized. False negatives may be bugs or enhancements (depending on semantics).
Deprecated lints are lints that we plan to remove.
Reasons for deprecation include:
Lints we no longer support are removed.
In general removal is preceded by a period of deprecation.
Once a lint proposal is accepted, it is safe to implement. A change that lands a new lint should have a corresponding CHANGELOG
entry.
Implemented lints can be deprecated.
Deprecating lints that are in common lint sets (e.g., in package:lints can be impactful so should be done with care.
(NOTE: A change that deprecates an existing lint should have a corresponding CHANGELOG
entry.)
Experimental lints should aspire to be stable. An experimental lint is a candidate for stable when it has
Deprecated or experimental lints can be removed. A stable lint should be deprecated before removal.
(NOTE: A change that removes an existing lint should have a corresponding CHANGELOG
entry.)