A public API is deprecated in a release before it is removed
Removing an API without warning turns an upgrade into an outage. Users need a released version where the old path still works and the interface they use directs them to the replacement.
Observable check
every public item under Removed appeared under Deprecated in an earlier release, stayed usable for the project's stated deprecation window, and produced an interface-appropriate notice naming the replacement or migration path and earliest removal version. For stable SemVer, deprecation ships in a MINOR release and removal waits for a later MAJOR release. A project that has removed no public item falls outside this rule rather than satisfying it with nothing to check.
Where this comes from
Last read against these sources on 2026-07-28.
Clause 7, read verbatim: 'Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.' That is the whole upstream basis for deprecating before removing. SemVer says nothing about how long a deprecation must stand or how it must be announced, so the notice period this rule requires is this standard's own position.