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
| Piece | Where it lives | How it is versioned |
|---|---|---|
The om CLI and daemon | Homebrew or the standalone installer | SemVer-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 schema | inside 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 under | abi_version in wrun/metadata.json | four: 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 workspace | an integer, 14 today; om wrun build migrates an older workspace forward once, non-destructively |
| The compiler | the 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 |
| Templates | om wrun templates | nine 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 alerts | the platform | deploy on their own schedule; a CLI feature can land before the chart honors it |
| These docs | this tree, llms-full.txt, and the authoring skill the agent reads | regenerated from one source per release; every sample compiles in CI |
What we publish
| Page | Purpose |
|---|---|
| Release notes | Version-by-version history of the Indicator surface, newest first: Added, Changed, Fixed, and Removed per release. |
| What's new | What Indicators add over kScript (legacy), in one read: browser compile, your own machine, metric ids, packages, declared shapes, celled inputs. |
| From kScript | The construct table, the port loop, and a worked RSI port. Not release history. |
| v1 vs v2 | Where 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_versionin 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-2adds the cell channel, the string channel, and the renderer and drawing vocabulary;wrun-3the handle-keyed draw channel, the strategy channel and the last-bar flag;wrun-4the frame channel and series inputs. Sheet-only additions (fills,ranges,boxes,segments,missing, thetimesource,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 nextom wrun buildrefreshes those files, never your source or your sheet, and reports the migration in the build's warnings. Version 7 added thebox(...)andsegment(...)declarations and the handleoutput(...)returns; 9 thestrategy(...)declaration and the whole TA library; 12 anchors on drawing handles; 13 thetapesource; 14 thealignword 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.0om 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_sha256before 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 updateshows which installed packages have a newer registry version and what changed;om packages updateinstalls the latest after one confirmation (--allfor 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/sdkandsrc/genfiles are yours to commit.
Upgrade checklist
- 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.
- Run
om upgrade, then rebuild every workspace withom wrun buildand read the warnings: a scaffold migration is reported there, and a compile error is the compiler's own diagnostic with a line and column. - Re-validate what is installed:
om wrun validateon each package directory, then oneom metric seriesper package to see a value move on real bars. - Move the alerts that should follow a new version with
om wrun upgrade, and leave the ones that should not: pins are a feature. - 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.