# Versions (editions)

A version — also called an **edition** — is a stable label that tells your application which feature set to unlock. A single product can ship as _Standard_, _Gold_ and _Platinum_ editions from the same codebase: each carries a different version, and your code switches on it. Every product has a default **“Full”** version (code `full`) until you define more.

A version is two things: a human-readable **label** (for example _Gold_) and a short, stable **code** (for example `gold`). Your application never reads the label — it reads the code.

## A version is attached through the SKU

A product can be assigned several versions. Which one a customer actually receives is decided **where the product meets the [SKU](/content/docs/dashboard/skus/index.html)**: when you put a product into a SKU, you pick the version it ships with there.

This means the same product can carry a **different edition in different SKUs**:

- _Photo Editor_ inside the **Standard SKU** ships with version `standard`.
- _Photo Editor_ inside the **Gold SKU** ships with version `gold`.

The customer activates one serial, KEYZY resolves the SKU → product → version, and the license your application receives already contains the right edition code. There is nothing extra to configure on the device.

## Why a version code, not the SKU name

Your SKU number and name are catalog data: you rename them, reprice them, retire and replace them as your offering changes. If your application branched on the SKU, every such change would risk breaking feature gating in shipped binaries.

A version **code is the stable contract** between your catalog and your code. You commit to `gold` once, and your application can trust it unconditionally — regardless of how the SKU around it is renamed or restructured later. Editions decouple “what your code checks” from “how you package and sell.”

This pays off most as your catalog grows, because **one version can live in many SKUs**. The same `gold` edition might back a dozen SKUs — different prices, regions, bundles, campaigns, renewals — yet your code still checks a single code. Without editions, your application would have to know every SKU name that counts as “gold”, and keep that list in sync as SKUs are added, renamed and retired. That is manageable for one SKU and a maintenance nightmare across many. An edition collapses that whole list back into one stable code.

## Reading the edition in your application

After a successful activation or validation, the edition code is available from the license. In the C++ SDK:

```
std::string version = pValidator->getVersion();   // e.g. "gold"

if (version == "gold") {
    // unlock Gold features
}
```

The same code is returned in the REST API as `version_code` on the validate response, so server-side and online flows can branch on it too. Because the code is fixed, the same binary handles every edition — you ship once and let the license decide what to turn on.