back to delimit.ai
Worked-example report v1 / Delimit team / 2026-07-14

What semver bump does my API change need?

A mixed diff, classified by the merge gate into one answer.

Delimit ran over the Twilio Messaging v1 OpenAPI between the twilio-oai 2.5.0 release (2025-09-04) and 2.6.9 (2026-05-07). 107 changes across nine change types: 9 breaking, 96 additive. The classifier resolves the whole set to a single bump.

What we scanned
Twilio Messaging v1
public OpenAPI
What we found
9 breaking · 96 additive
107 total changes
Change types
9
across major + minor
Semver verdict
major
highest tier wins
Why a worked example. Twilio ships its API definitions as versioned releases in the open, which makes a real multi-type diff easy to pin down.
  • twilio/twilio-oai is public; 2.5.0 and 2.6.9 are real tagged releases.
  • This is not a defect report and Twilio is not a Delimit customer. We use the diff only to show how the classifier behaves on a mixed change set.
  • Reproducible byte-for-byte (command at the end).

The problem

"What semver bump does my API change need?" sounds like a lookup and is actually a judgment across the whole diff. A release that adds 96 harmless things and changes 9 in a breaking way is not a minor release; it is a major one, because a single breaking change forces the bump. Get it wrong in the additive direction and you ship a breaking change under a minor version number, which is how consumers get surprised.

An AI assistant asked to "pick the version" will often reason from the majority of the diff, which is additive here, and land on minor. The merge gate reasons from the tiers instead.

The setup

Pass the current version and the gate returns the classified change set plus the recommended next version.

# .github/workflows/api-merge-gate.yml
name: API merge gate
on: [pull_request]

jobs:
  delimit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: delimit-ai/delimit-action@v1
        with:
          spec: spec/json/twilio_messaging_v1.json
          current-version: "1.0.0"

What free Delimit detects

Every change is assigned a change-type and a semver tier. 9 changes land in the major tier, 98 in the minor tier. The counts below are the real distribution for this diff.

Change typeCountTierWhat it is
response_type_changed4majorresponse schema shape changed on USA2P compliance reads
type_changed4majordeclared type of a schema member changed
additional_properties_tightened1majora schema stopped allowing extra properties
optional_field_added48minornew optional response/request fields
enum_value_added42minornew accepted enum values
optional_param_added5minornew optional query/path parameters
nullability_added2minora field may now be null (additive for readers)
endpoint_added1minorone new route

No change in this diff fell in the patch tier (documentation-only or deprecation-flag changes). The taxonomy still defines that tier; this particular release just did not exercise it.

The classification rule

The rule is the standard semantic-versioning precedence: the bump is the highest tier present in the change set. Nine major-tier changes are enough on their own; the 96 additive changes cannot pull the answer down. So a release that is 90% additions is still a major release, and the gate recommends the next major version.

major-tier
9
forces the bump
minor-tier
96
outvoted
verdict
major
e.g. 1.0.0 → 2.0.0

Why a generic AI review misses it

Ask a model "what version should this be?" and it weighs the diff narratively. When 96 of 107 changes are safe additions, the story reads "big additive release," and the model reaches for minor. The nine breaking changes are a rounding error in prose and a decisive factor in semver. The two readings disagree, and only one of them is the rule.

The gate does not weigh the diff. It classifies each change, takes the maximum tier, and returns the same answer every run.

Reproduce locally

# Install the CLI
npm install -g delimit-cli

# Clone the spec repo
git clone https://github.com/twilio/twilio-oai
cd twilio-oai

# Extract the two tagged releases
git show 2.5.0:spec/json/twilio_messaging_v1.json > /tmp/old.json
git show 2.6.9:spec/json/twilio_messaging_v1.json > /tmp/new.json

# Run the merge gate with a current version to get the bump
delimit lint --current-version 1.0.0 /tmp/old.json /tmp/new.json

If your bytes differ from this report, raise it on the Delimit repo.

Free detects. Pro proves.

Free Delimit is the merge gate: it classifies the diff and tells you the bump on every pull request. Install delimit-cli or add the delimit-ai/delimit-action to CI. Free for individual maintainers.

Pro turns the version verdict into a signed, replayable attestation: a portable record of the classified change set and the recommended bump that a reviewer or downstream consumer can verify without rerunning the gate. Pro tier $10/month for teams.

Delimit team / worked-example report v1 / 2026-07-14attestation methodology

Reproducibility: re-run the same Delimit version against the same release pair and the diff is byte-identical. Subject API: Twilio Messaging v1 OpenAPI, spec/json/twilio_messaging_v1.json. Releases: twilio-oai 2.5.0 (2025-09-04) and 2.6.9 (2026-05-07).

The merge gate for AI-written code, with signed, replayable attestation. Works with Claude Code, Codex, Cursor, and Gemini CLI.

Add the GitHub Action
- uses: delimit-ai/delimit-action@v1
  with:
    spec: api/openapi.yaml

Free, no account. Point spec at your OpenAPI file.

What the attestation proves

A signed, replayable attestation is a bounded evidence record of what an AI-assisted merge changed and how the change was classified. It is replayable: re-run the same Delimit version against the same inputs and the result is byte-identical, so a reviewer can verify it without re-deriving the diff. It is the artifact your reviewers or downstream consumers can read straight from the merge gate for AI-written code.

Read the docs
See pricing

Free tier runs the full gate. Pro is $10/mo.