Skip to content
Rival Docs

Versions

Every published tool on Rival has at least one version. Every time you publish (either privately or publicly), a new version is created. Versions are the unit of deployment: each one captures a complete snapshot of your tool at a point in time and makes that snapshot permanently callable.

What a version contains

A version isn’t just code. It bundles together everything that defines how the tool behaves:

  • The handler code and runtime
  • The input schema (parameter names, types, validation)
  • Saved events and test cases
  • The pricing model (Free, Paid, or Private)
  • The changelog entry

All of these are frozen together at publish time. Callers who depend on a specific version can trust it won’t change underneath them.

Semantic Versioning and version bumps

Rival follows semantic versioning, with version numbers generated automatically based on the bump you choose at publish time:

  • Patch - bug fixes, small tweaks (0.0.1 → 0.0.2)
  • Minor - new features, backwards compatible (0.0.1 → 0.1.0)
  • Major - breaking changes (0.0.1 → 1.0.0)

You don’t type a version number - you pick the bump and Rival assigns the next one. The version number then appears on the tool’s Marketplace detail page and is part of the API invocation URL, so callers can pin to it explicitly.

Immutability

Once a version is published publicly, it is immutable. The code, the schema, the pricing - nothing about that version can change after the fact. If you need to fix a bug or add a parameter, you publish a new version. The old one stays available and callable for anyone who already integrated with it.

A version published as Private (visible only to your organization) remains mutable - you can edit it from the Tool Editor and re-publish. Once you flip it to Public, it locks.

Public version vs older versions

A tool’s Marketplace listing shows the latest public version by default. The other public versions can be chosen from the dropdown on the details page itself.

From the Tool Editor (available to the tool’s editor), open the version dropdown to see the full history of published versions. From there you can view their code, their changelog entries, and more.

Callers can always target a specific version explicitly through the API - the listing’s “public” version is about discoverability, not access.

Drafts

While you’re building or editing, the tool is in a draft state. Drafts are not callable, not versioned, and not visible on the Marketplace. Publishing turns the draft into a new version.

If a tool already has a published version, any further edits you make go into a new draft. The live version stays exactly as it was until you publish the draft - so you can iterate freely without affecting anyone using the tool today.

The changelog

Every published version can include a changelog entry - a short note describing what changed. The full changelog is displayed on the tool’s Marketplace detail page in reverse chronological order, so callers can see how the tool has evolved and decide when to upgrade.

Clear changelog entries make a real difference for tools with active users. “Added a language parameter for non-English input” is far more useful than “minor changes.”

Where to view version history

  • Tool Editor → Preview Tab → Versions panel: full history for your own tools, including drafts and private versions.
  • Marketplace Tool detail page → Changelogs: public-facing list of published versions and their changelog entries.

See Versions & Publishing for the workflow of cutting a new version.