^0.2.0 does not accept 0.3.0: pinning @sume-com/sdk in npm

Short answer

A caret range allows changes that do not modify the left-most non-zero digit, so ^0.2.0 means >=0.2.0 <0.3.0-0, per the node-semver README. For @sume-com/sdk, currently published as 0.2.0, a caret range will take 0.2.x patch releases but never 0.3.0. A minor bump needs a deliberate edit of package.json, which is the safe behavior for a pre-1.0 package.

How the caret behaves

npm describes ^version as compatible with version. The precise rule lives in node-semver, and the examples below come from its README. The further left the first non-zero digit sits, the narrower the range.

What it means for the Sume SDK

The SDK docs describe @sume-com/sdk@0.2.0 as MIT licensed with no runtime dependencies. Under 0.x, the caret treats 0.3.0 as a different compatibility line and does not install it on its own. That is good for production, because nothing about a 0.x version number promises that a minor release keeps every behavior you rely on. It also means a fresh install will not silently move you to a newer minor when you run npm update.

The practical effect is that you control the upgrade. When you decide to move, read the release notes, bump the range by hand, run your offline tests and then your live smoke check.

A floor for the features you rely on

Pin a floor as well as a ceiling. The webhook docs state that verifyWebhook in 0.2.0 handles the multi-signature header that Sume sends for 24 hours after a signing secret rotation. A hand-rolled verifier that compares the header for equality fails on every delivery during that window. If your code depends on 0.2.0 behavior, say so in the range, and let the lockfile record the exact version CI installs.

{
  "dependencies": {
    "@sume-com/sdk": "^0.2.0"
  }
}

CI habits that help

Install from the lockfile in CI so every run uses the same version, and make version bumps a pull request of their own. A bump pull request should run the full offline suite, including webhook verification tests with signed fixtures and a fake-fetch retry test, and then one live read-only call. If an upgrade changes error handling, you want that to fail a test, not a customer.

Choosing a range style

There are three common choices. An exact version such as 0.2.0 never moves, which is the strictest and the most work. A caret range such as ^0.2.0 takes patch releases within 0.2.x. A broader range such as >=0.2.0 accepts anything newer, including a future 1.0 with breaking changes, so it suits only a library that tests against a matrix.

For an application that spends money through the SDK, the caret on the current minor, together with a committed lockfile, is a reasonable default: patches arrive, minors wait for a human.

• Exact pin: no movement, most manual.
• Caret on the minor: patch updates only while the major is 0.
• Open floor: accepts any newer version, including breaking ones.

After the 1.0 release

Once a package reaches 1.0, the same caret means something wider. Per the README, ^1.2.3 allows >=1.2.3 <2.0.0-0, so minors and patches flow in. Remember to revisit your ranges and your test suite at that point, because a caret that was conservative at 0.x becomes permissive at 1.x.