agent auto-merged a "minor" bump that removed a deprecated endpoint - the package used calver and the agent treated...

TL;DR: Detect calendar versioning before trusting the version number: if the version looks like a date (2024.10, 24.10.0), treat every bump as potentially breaking and require release-notes review before automerge. Maintain a list of known calver packages in your stack and gate the agent's automerge on it. The version number is a timestamp, not a compatibility promise.

agent auto-merged a "minor" bump that removed a deprecated endpoint  -  the package used calver and the agent treated it as semver

1. Confirm the versioning scheme: check the package's recent versions for date-shaped numbers (year.month) or a documented calver policy in its README.

Expected: versions like 2024.10.0, confirming calver.

1. Revert or pin the breaking bump if the removed endpoint is still needed, and fix the call sites to the new API if you are keeping the new version.

Expected: the build is green again, on the old or the new API consistently.

1. Add the package to a calver list in the agent's config and disable automerge for it (or require a release-notes check before merge).

Expected: future bumps to this package stop and wait for review.

1. Teach the agent a versioning-scheme check: before auto-merging any "minor" or "patch," verify the package follows semver (or is on the known-semver list); date-shaped versions always require notes review.

Expected: unknown schemes default to manual review, not automerge.

1. On the next bump of a calver package, confirm the agent posts the release notes excerpt and waits instead of merging.

Expected: a human sees what changed before anything merges.

Use this when

• a minor or patch bump removed an API or changed behavior
• the package versions look like dates (2024.10, 25.1.0)
• automerge keeps landing breaking changes from "safe" bumps
• the project's docs mention calendar versioning

Not for this skill when

• the package is true semver and the break was a genuine semver violation (report it upstream; different problem)
• the break came from a 0.x package (see the 0.x skills)
• you already review every bump manually (then automerge was never the risk)

Variant phrasings

• "calver treated as semver broke automerge"
• "minor bump removed deprecated endpoint"
• "how to detect calendar versioning in dependencies"
• "auto-merged breaking change from date-versioned package"
• "package uses calver not semver"

Why it happens

Agents assume semver because most of the ecosystem uses it: minor means features, patch means fixes. Calver uses the version as a release timestamp, so "minor" and "patch" positions carry no compatibility meaning at all - a "patch" can remove an endpoint. Nothing in the version string warns you; only the shape (year.month) or the docs reveal the scheme.

Edge cases

• Some projects mix schemes (calver for the app, semver for the library); check the specific package, not the org.
• A calver package can still document breaking changes clearly in its notes; the rule is "read the notes," not "never automerge."
• Date-shaped versions with a real semver policy exist (uncommon but real); the docs are the tiebreaker, not the shape.
• Deprecated-endpoint removals are the classic calver surprise; grep the notes for "removed" and "deprecated" before approving any calver bump.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hoKz1szB6BdWNE95BBQtlg