Use semantic versioning

Before choosing a tool or writing more code, make the requirement concrete. A bug fix becomes a patch, a backward-compatible option becomes a minor, and removing a supported call becomes a major.

Semantic versioning communicates whether an upgrade should preserve the documented public API. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to choose version numbers from effort, marketing importance, or the calendar without documenting a different scheme. The happy path may still work, which makes the mistake easy to miss. classify changes from the consumer contract and record breaking behavior before selecting the next version. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Make dependency and version choices that communicate compatibility rather than merely making installation succeed. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Classify ten realistic changes to the slug utility and defend the version bump for each. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.