agent treated 0.x minor bumps as safe; the package dropped python 3.9

Not specified by the original author.

TL;DR: Treat every 0.x minor bump as a major: under semver, anything may change before 1.0, including dropping runtime support. Require release-notes review and a full CI pass before merging any 0.x bump, and check the package's supported-runtimes metadata against your own. The "minor" label on a 0.x version promises nothing.

agent treated 0.x minor bumps as safe; the package dropped python 3.9 support in 0.14.0 and CI died

1. Confirm what broke: read the CI failure and check the package's changelog or metadata for the dropped support (python_requires, engines field, or supported-versions doc). Expected: the 0.14.0 release notes or metadata show python 3.9 removed.

2. Decide: either pin the package below 0.14.0 until you can move off python 3.9, or upgrade your runtime and take the bump. Expected: a deliberate choice, not a surprise; CI green on the chosen path.

3. Change the agent's automerge rule: never automerge 0.x bumps; require notes review and a passing CI run first. Expected: future 0.x bumps wait for a human or at minimum a full CI pass.

4. Add a runtime-support check to the agent's pre-merge verification: compare the package's declared supported runtimes against the runtimes you actually run. Expected: dropped-support bumps get flagged before merge, not after CI dies.

5. Verify on the next 0.x bump: the agent posts the notes, runs CI, and does not merge on its own. Expected: no more silent 0.x merges.

Use this when

• a 0.x minor bump broke CI or dropped platform support
• the agent automerges 0.x bumps as if they were safe
• the package is pre-1.0 and moves fast
• you run older runtimes the package may stop supporting

Not for this skill when

• the package is post-1.0 semver and broke the contract (report upstream)
• the break was a real bug in the new version, not a support drop (pin and report)
• you have already migrated off the dropped runtime (then just take the bump)

Variant phrasings

• "0.x minor bump dropped python support"
• "pre-1.0 minor treated as safe broke CI"
• "how to handle 0.x dependency upgrades"
• "package dropped node version in 0.x minor"
• "semver 0.x anything may change"

Why it happens

Semver is explicit: major version zero is for initial development, and anything may change at any time. But agents pattern-match "minor bump = safe" from the far more common post-1.0 case and never special-case the leading zero. Dropping a runtime is exactly the kind of change a maturing 0.x package makes in a minor, and it kills CI on every project still on the old runtime.

Edge cases

• Some 0.x packages are de facto stable (years of 0.x with a strict changelog); you can allowlist those individually, but keep the default strict.
• The python_requires or engines field usually declares the drop before CI discovers it; read metadata first, it is cheaper than a red build.
• A 0.x package can also ADD a required runtime (needs python 3.11+ for a new feature); the support check must catch new minimums, not just drops.
• If you must stay on the old runtime, pin the 0.x package and set a calendar reminder to revisit; pins rot silently.

Provenance

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

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

Thread query: agent treated 0.x minor bumps as safe; the package dropped python 3.9 support in 0.14.0 and CI died

TL;DR:

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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

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

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

TL;DR:

Not specified by the original author.

TL;DR

Check the actual API diff before the agent assigns a version bump. The agent looked at commit messages or at the size of the diff, not at whether public signatures changed, so removals and renames shipped as minor. Fix: diff the public API surface between releases, flag any removal, rename, or signature change as breaking, and require a major bump plus a changelog callout.

The error

docs agent failed: mislabeled breaking change as minor

Steps

1. Diff the public API between the two releases: compare exported functions, classes, parameters, and config keys. Tools like a TypeScript API extractor, cargo public-api, or a simple export list diff work. Expected: a list of removed, renamed, and signature-changed symbols.

2. Confirm the break against the published changelog: find the entry the agent wrote and its version label. Expected: you see the breaking symbol listed under a minor or patch heading.

3. Correct the record: bump to the next major version (or mark the release as breaking) and add an explicit BREAKING CHANGE section naming each removed or renamed symbol and its replacement. Expected: the changelog states plainly what breaks and how to migrate.

4. Teach the agent the rule: any removal, rename, required-parameter addition, default change, or return-type change in the public API is breaking, regardless of what the commit message says. Expected: the agent's version-labeling step consumes the API diff, not just commit text.

5. Add a CI check that fails the release when the API diff shows breaking changes but the planned bump is minor or patch. Expected: mislabeled releases are blocked before publishing.

Use this when

• users report breakage after upgrading a minor or patch release
• the changelog labels a release minor but the API surface shrank or changed
• the agent assigns version bumps from commit messages alone

Not for this skill when

• the version is right but the changelog text is vague (a writing issue)
• the break came from behavior change with identical signatures (harder; needs behavioral diffing)
• you are deciding initial 0.x versioning policy (a policy question)

Variant phrasings

• breaking change shipped as minor release
• agent labeled API removal as non-breaking
• semver mislabeled by docs agent
• changelog says minor but clients break on upgrade

Why it happens

The agent classifies by proxy signals: commit message wording, diff size, or the author's own label. None of those reliably indicate compatibility. Only the public API diff tells the truth, and the agent never computed it.

Edge cases

• Deprecations are not breaks: marking something deprecated is minor; removing it later is major.
• Config key renames and default value changes count as breaking even though no function signature changed.
• 0.x versions: breaking changes may go in minor bumps by convention, but the changelog must still call them out explicitly.

Provenance

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

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

Thread query: docs agent failed: mislabeled breaking change as minor

TL;DR: Check the actual API diff before the agent assigns a version bump. The agent looked at commit messages or at the size of the diff, not at whether public signatures changed, so removals and renames shipped as minor. Fix: diff the public API surface between releases, flag any removal, rename, or signature change as breaking, and require a major bump plus a changelog callout.