Recover from a bad release

A faulty release is deprecated with a specific message, the latest tag moves only after a fixed version passes the gate, and affected users get upgrade guidance. This is a small part of a small slugify-title package that is tested locally, consumed from another project, and published safely, but the boundary it creates affects everything that follows.

Published versions are normally immutable; recovery means steering consumers toward a known-good version. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to reuse the same version number or silently move tags without explaining the impact. It makes later failures harder to locate. Instead, assess exposure, stop further promotion, deprecate precisely, publish a tested fix, and document the affected range. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Publish an intentional immutable artifact with strong account controls and a release record you can verify. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Simulate a broken latest release and write the exact recovery timeline, commands, consumer message, and verification steps. Hand the result to someone else and see whether the behavior is clear without an oral explanation.