Releases

Overview

How kScript versions are documented, what to expect in each release entry, and where to find migration context when upgrading from older language versions.

Release notes document what changed in kScript as it ships on the OpenMarket platform: new language features, fixes, performance work, and any breaking changes that may require you to update scripts.

They are written for script authors first—concrete behavior changes and upgrade impact—not internal implementation detail.

What we publish

ArtifactPurpose
Release NotesVersion-by-version history: highlights, grouped changes, and breaking-change callouts.
Migration (v1 vs v2)Migrate from v1 to v2—conceptual differences. Not release history—use Release Notes.
Migration (v2 vs v3)Migrate from v2 to v3: the version marker, corrected TA warmups, and what got stricter. Not release history: use Release Notes.

New work is listed in Release Notes newest first. Each entry uses a short headline plus sections such as Added, Changed, Fixed, and Breaking changes so you can scan quickly.

Versioning

kScript releases are identified by semantic-style version numbers (MAJOR.MINOR.PATCH):

  • MAJOR — Breaking language or runtime behavior, or removals that require script changes.
  • MINOR — New features or compatible improvements.
  • PATCH — Bug fixes and small compatible adjustments.

When a release includes breaking changes, its Release Notes entry calls them out explicitly and points to relevant manual sections where possible.

Upgrade checklist

The //@version marker is a language-generation marker, not a release number: //@version=2 and //@version=3 are both accepted and select the same modern engine (see v2 vs v3), so a newer runtime never requires bumping it. What the marker must never be is missing or //@version=1; both route the script to the deprecated legacy v1 engine. When you redeploy scripts against a newer runtime:

  1. Read the Latest release callout at the top of Release Notes.
  2. Scan Breaking changes for your current and target versions.
  3. Re-compile scripts in the editor and fix any compile-time errors first (v2 favors early errors over runtime surprises).
  4. Validate indicators on historical and live data where behavior may depend on timing or data subscriptions.