---
title: Overview
description: >-
  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

| Artifact                                      | Purpose                                                                                                                |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| [Release Notes](/kscript/releases/changelog) | Version-by-version history: highlights, grouped changes, and breaking-change callouts.                               |
| [Migration (v1 vs v2)](/kscript/migrations/v1-vs-v2) | **Migrate** from **v1** to **v2**—conceptual differences. Not release history—use [Release Notes](/kscript/releases/changelog). |

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](/kscript/releases/changelog).
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.

{% hint style="info" %}
**Docs vs platform:** Published dates reflect when changes reached the documentation snapshot; your organization’s rollout timing may trail or lead **Release Notes** slightly. Treat **Release Notes** as the authoritative _behavior_ list for a given version tag.
{% endhint %}