Deprecate and retire

The final release removes secrets and automation, points to a maintained alternative, and states whether security reports are still handled. 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.

Abandoned packages create lasting risk because installations continue after maintainers stop watching them. 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 delete the repository or unpublish without warning and leave consumers guessing. It makes later failures harder to locate. Instead, announce a timeline, deprecate versions with a useful message, document migration, and preserve the namespace safely. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Maintain the package as a promise to consumers, with explicit support, measured changes, and a retirement path. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Write a retirement notice and test that a new install clearly directs the user to the replacement. Hand the result to someone else and see whether the behavior is clear without an oral explanation.