Versioning

This page explains how Binoban versions the things you integrate against, so an upgrade never surprises you. It's understanding-oriented — for the actual list of what changed, see Release notes and the Changelog.

Why this matters

Your integration is built on contracts: the methods an SDK exposes, the shape of an API request, the meaning of an event name. As long as those hold, your code keeps working. Versioning is how Binoban tells you when a contract is stable, when it has grown, and — rarely — when it has changed in a way that needs your attention.

Three things version together

What	The contract it carries
SDKs (Web, Native, React Native)	Method signatures, configuration keys, on-the-wire payloads
APIs (Tracking, Sync, Ad-Request, …)	Endpoints, request/response shapes, auth
These docs	The description of the two above

They move as a set: a docs page describes a specific contract version, and the SDK/API it documents implements it. When you pin an SDK version in production, you're pinning the contract the matching docs describe.

Safe changes vs. breaking changes

Not every change carries the same risk:

• Additive (safe). New optional methods, new optional fields, new event types. Existing code keeps working untouched. Most releases are additive.
• Breaking. A removed or renamed method, a changed required field, a changed default. These are the ones that can affect a running integration, so they're called out explicitly in Release notes with migration guidance — never shipped silently.

When in doubt, treat additive as the norm and breaking as the exception that is always announced.

How a docs page tells you its status

Every page in these docs carries front-matter that signals how much you can lean on it:

• status — where the page (and the contract it describes) stands:
  • draft — being written or describing an unreleased contract; don't build against it yet.
  • active — current and supported; safe to integrate against.
  • deprecated — still works, but a newer path exists; plan to migrate.
• version — the contract version the page documents.
• last_updated — when the page was last revised.

If a page is draft, the structure is settled but the detail may still change — useful for planning, not yet for production.

Contract-reference policy

A few habits keep your integration stable over time:

• Pin versions in production. Pin your SDK version and integrate against an active contract; upgrade deliberately, not automatically.
• The docs describe the contract, not your deployment. On-prem and air-gapped deployments may run a specific pinned version; confirm which contract version your deployment ships against if you're unsure.
• Watch Release notes before upgrading. That's where breaking changes and migration steps live.

Where to go next

• Release notes — what changed and what it means for you.
• Changelog — the chronological log.
• SDK compatibility matrix — versions and status per SDK.