Normal SDK releases follow a monthly cycle. Nonurgent fixes and features ship together; security, privacy, application outages and material data-loss fixes can use an expedited patch outside the cycle. A new release alone does not require a customer upgrade. Review optional upgrades quarterly; recommend an update for a verified affected defect, a requested feature or an announced support deadline.
Qualification and support
Ordinary major and minor releases have a seven-day release-candidate window with internal dogfood and explicitly authorized customer canaries. Retain the exact packed versions, installation results, scenario coverage and observed traffic; elapsed time alone is not a pass. Critical patches use focused qualification for the affected setup and regression, with the reason for expediting recorded. Release authorization remains a separate gate.
A patch corrects compatible behavior without adding capture, propagation targets or headers, changing consent, or changing instrumentation ownership. An additive opt-in capability can be minor; incompatible defaults or contracts require a major. After v13 becomes generally available, the final v12 line retains ingestion/config compatibility and critical/security fixes for twelve months, with ninety days’ notice before support ends.
Network in every release note
Every SDK release note includes a Network section, even when the answer is “unchanged.” Compare the exact previous and target versions. List headers added, removed or changed; the destinations and methods that receive them; retries of application requests separately from retries of SDK telemetry; and changes to data sent, consent and privacy. Include required CORS allow-list changes and deployment order. Do not call a successful build or a same-origin preview proof that a cross-origin production API will work.
13.0.0-rc.2 candidate: Network
This describes the rc.2 candidate relative to rc.1, not a stable-release announcement. For a 12.x upgrade, also review the rc.0 and rc.1 package changelogs: cumulative changes include namespaced session/device baggage, service-identity headers on SDK requests and removal of telemetry-triggered application-request retries.
| Area | Candidate behavior and review required |
|---|---|
| Browser headers | No new header names in rc.2. Every tracing ownership mode can write traceparent and tracestate when absent, plus permitted baggage. An existing traceparent is preserved; Datadog configured for W3C tracing and Sentry configured to propagate traceparent retain ownership of that header in auto/application mode. Choosing application mode alone does not disable header writes. |
| Browser origins and methods | The page origin and explicit tracing.propagateTo origins receive the selected headers. Workspace-discovered backend hosts map to exact HTTPS origins: GET/HEAD can carry headers immediately; other methods carry them only after a header-bearing GET/HEAD has answered in that browser session. Other origins receive none. Sibling domains, ports and schemes are separate origins. |
| Header controls and CORS | tracing.headers: false disables Interfere header writes; a list restricts them globally, and { origin, headers } in propagateTo selects an origin’s list. Check the actual Access-Control-Allow-Headers policy for every used header, including baggage. A prior successful GET is not proof for every method, route, credential mode or later CORS policy. |
| Server requests | Managed Next/Vercel drain mode now adds configured backend HTTPS origins to server fetch propagation, alongside explicit server propagateTo. Application-owned instrumentation remains controlled by the application. This server setting does not authorize browser CORS. |
| Retries and delivery | No application request is retried by Interfere. An initial network-layer failure can suppress later SDK headers to that origin for the browser session; the original request remains failed. Telemetry retries remain separate. rc.2 also resumes queued hidden-page telemetry when replay releases keepalive capacity, changing delivery timing rather than adding application calls. |
| Data sent | identity.set({ company: { tier } }) adds the supplied company tier to session identification, including tier changes. Existing consent controls still apply. Header configuration limits what Interfere writes, not another SDK’s headers or telemetry. |
Customer preview checklist
Use an SDK-only upgrade PR: SDK configuration, required package/lockfile changes and evidence belong together; unrelated application changes belong elsewhere. Copy the repository’s sdk-upgrade.md PR template into the customer upgrade body.
- Pin the exact candidate, preserve the existing service name and keep the application’s tracing owner and exporters.
- Record the package manager’s release-age policy, earliest installation date and approved exclusion or one-off override, including fresh transitive Interfere packages. Restore the normal policy and prove a frozen-lockfile install in CI. Stable publication starts a new age clock.
- Confirm the preview actually loads and enables the SDK with the intended key, build configuration and consent. A preview with the SDK disabled is not network qualification. If a customer policy forbids enabling it, leave the check blocked until a separately authorized environment is available.
- Compare preview and production browser origins, API origins, methods, credential modes, redirects, tracing vendors and CORS rules. Check the real API configuration, not just a hostname substitution.
- Start with a fresh browser session and preflight cache. Exercise
GET/HEADand the firstPOST/PUT/PATCH/DELETEbefore any successful read, then repeat after a read and after reload. Include authenticated writes such as a save; verify their response and resulting application state. - Inspect browser network evidence for exact outgoing headers, OPTIONS responses, successful application calls, and absence of duplicate sends. Repeat with the SDK disabled to isolate its effects. Redact credentials and personal data from retained evidence.
- Verify errors, allowed replay, session correlation, source maps and existing vendor telemetry in their destinations. Record missing samples as unproven.
- Deploy any required API CORS allow-list changes before enabling the SDK headers. Record the prior package/configuration/lockfile and preview rollback result. A server redeploy alone does not replace an already loaded browser bundle; verify a fresh load after rollback.
The reviewer needs the exact versions and preview revision, CI run, representative browser evidence, result for each check and a rollback owner. Do not replace missing runtime evidence with “build passed.”