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 Kiyotaka 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.

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

When you bump the //@version annotation or 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.