Releases overview

How Indicator releases are versioned, what each one carries, how om upgrade moves your machine onto it, and the checklist to run afterwards. kScript (legacy)…

How Indicator releases are versioned, what each one carries, how om upgrade moves your machine onto it, and the checklist to run afterwards. kScript (legacy) versions its engine; Indicators version the CLI that builds and runs them, and pin two things separately from it: the contract (abi_version) a package declares and the scaffold contract a workspace carries.

What ships

PieceWhere it livesHow it is versioned
The om CLI and daemonHomebrew or the standalone installerSemVer-style 0.MINOR.PATCH; one tag per release (chore(release): vX.Y.Z) is the source of truth for what is out
The runtime and the sheet schemainside the CLI (the @openmarket/sdk package)move with the CLI; the schema's conformance corpus is vendored verbatim by the chart backend and the registry so every host refuses the same sheets
The contract a package runs underabi_version in wrun/metadata.jsonfour: wrun-1 (absent means this; frozen forever), wrun-2 (cells, text, declared drawings), wrun-3 (handles, strategies, the last-bar flag), wrun-4 (frames and series inputs); each is additive over the one before
The scaffold contract.wrun-scaffold in a workspacean integer, 14 today; om wrun build migrates an older workspace forward once, non-destructively
The compilerthe workspace's package.json (assemblyscript)the range ^0.27.0, resolving to 0.27.37; the chart's editor loads exactly that version, so both hosts emit the same bytes
Templatesom wrun templatesnine today: sma-codefirst, sma-box, sma, vp-buy-share-codefirst, polymarket-odds, conviction-score, event-asset-divergence, escalation-risk, hud-terminal
The chart's editor and hosted alertsthe platformdeploy on their own schedule; a CLI feature can land before the chart honors it
These docsthis tree, llms-full.txt, and the authoring skill the agent readsregenerated from one source per release; every sample compiles in CI

What we publish

PagePurpose
Release notesVersion-by-version history of the Indicator surface, newest first: Added, Changed, Fixed, and Removed per release.
What's newWhat Indicators add over kScript (legacy), in one read: browser compile, your own machine, metric ids, packages, declared shapes, celled inputs.
From kScriptThe construct table, the port loop, and a worked RSI port. Not release history.
v1 vs v2Where the two kScript generations go: Indicators have no language versions; both port through the same construct table.

New work is listed in Release notes newest first. Each entry opens with a bold headline and groups changes so you can scan: Added, Changed, Fixed, Removed.

Versioning

Three numbers matter, and they move independently:

  • The CLI version (om --version, 0.398.1 as this page is written). Minor bumps carry features, patch bumps carry fixes; the changelog names each. A newer CLI never requires changing a package that already builds: the ABI and the scaffold contract below are what a package and a workspace actually depend on.
  • The contract version (abi_version in the sheet). The first contract, wrun-1, is FROZEN: its import allowlist, export contract, and behavior never change, and every published package on it keeps running bit-identically forever. Each later contract is ADDITIVE over the one before and freezes in turn: wrun-2 adds the cell channel, the string channel, and the renderer and drawing vocabulary; wrun-3 the handle-keyed draw channel, the strategy channel and the last-bar flag; wrun-4 the frame channel and series inputs. Sheet-only additions (fills, ranges, boxes, segments, missing, the time source, displacement_bars) are contract-neutral and legal on every one. A package declares its contract once; nothing else selects it.
  • The scaffold contract (.wrun-scaffold). It counts the generation of the files the scaffold owns: src/sdk/*, src/gen/*, the prebuild script, the build scripts. When a release bumps it, the next om wrun build refreshes those files, never your source or your sheet, and reports the migration in the build's warnings. Version 7 added the box(...) and segment(...) declarations and the handle output(...) returns; 9 the strategy(...) declaration and the whole TA library; 12 anchors on drawing handles; 13 the tape source; 14 the align word on label handles.

A release that changes behavior a package could observe says so under Changed and names the surface; a release that removes a command or a field says so under Removed. Metric values never change under an upgrade: an installed package pins its wasm_sha256, and an alert pins the exact package version and hash it was armed on.

How om upgrade moves it

om upgrade
om wrun build ./my-indicator
om wrun validate ./my-indicator
om metric series --metric wrun/@you/my-indicator/sma --params period=20 --symbol BTCUSDT --exchange BINANCE_FUTURES --bars 30
om packages list --status update
om packages update --all
om wrun upgrade @you/my-indicator --version 0.2.0

om upgrade updates om to the latest release and restarts the daemon on it (a Homebrew install delegates to brew; a standalone install self-replaces; --no-restart leaves the running daemon on the previous binary). What stays put across it:

  • Installed packages keep running. Their modules are verified against wasm_sha256 before every run and never rebuilt by an upgrade.
  • Alerts keep their pins. An alert references the exact version and hash it was armed on. A newer version of the same package, installed from the registry or from your workspace, does not move an alert until om wrun upgrade <package> --version <x> re-pins its locks.
  • Registry packages update on your say-so. om packages list --status update shows which installed packages have a newer registry version and what changed; om packages update installs the latest after one confirmation (--all for every outdated package).
  • Workspaces migrate on their next build. A workspace scaffolded by an older release is lifted onto the current scaffold contract once; the refreshed src/sdk and src/gen files are yours to commit.

Upgrade checklist

  1. Read the newest entry in Release notes and scan Changed and Removed for the surfaces you use: the sheet fields, the commands, the chart lanes.
  2. Run om upgrade, then rebuild every workspace with om wrun build and read the warnings: a scaffold migration is reported there, and a compile error is the compiler's own diagnostic with a line and column.
  3. Re-validate what is installed: om wrun validate on each package directory, then one om metric series per package to see a value move on real bars.
  4. Move the alerts that should follow a new version with om wrun upgrade, and leave the ones that should not: pins are a feature.
  5. If a rebuild changed a published package's sheet, publish a bumped version; published versions are permanent.

Docs vs platform

The chart's editor, the hosted alerts engine, and the registry deploy separately from the CLI, so a capability can exist on your machine before the chart honors it. The three cases today: the chart reads its own market and interval for every input (symbol, exchange, and interval pins are honored on your machine), om chart indicator preview refuses an output with a nonzero displacement_bars, and hosted Indicator alerts armed from the chart run where the site has them switched on and read candles only. Each is called out on the page that documents the feature (Execution model has the table of hosts), and Release notes records when the platform side lands. Treat Release notes as the authoritative behavior list for a given CLI version.