> Lettrove docs 1.0 · https://docs.lettrove.com/docs/1.0/editor/releases

# Releases and pinning

The editor is served from `lettrove-embed.com`, not from your bundle, so it improves without you
redeploying. You choose how much it may change under you with the `release` option.

## What you can ask for

| `release` | Your users get | Changes when |
|---|---|---|
| left out | The newest **1.x** — what the installed `@lettrove/embed` was built for | We release a 1.x: new features (switched off until you use them) and fixes |
| `'1'` | The newest 1.x | Same |
| `'1.2'` | The newest **1.2.x** | Only bug fixes |
| `'1.2.3'` | Exactly **1.2.3**, forever | Never (except a critical security fix, announced) |
| `'stable'` | Whatever we have marked stable | We move the channel |

```ts
createEditor({ /* … */ release: '1.2' }); // fixes only, never new features
```

Within 1.x nothing is taken away and no option changes meaning, so following `'1'` is safe; pinning
is for teams that want to test each release before their users see it.

`editor.release` (and `ready`'s `release`) tells you the exact version running.

## A release that is withdrawn

If a release has a critical security problem, it is **withdrawn**: anyone pinned to it is moved to
the release that fixes it, and the release notes say why.

## Release candidates

Before a release, we publish **release candidates** such as `1.3.0-rc.1`, for you to try:

- On npm under the `next` tag: `npm install @lettrove/embed@next`. A plain `npm install` never
  picks a release candidate. (Before 1.0.0 was released on 11 October 2026, the 1.0.0 release
  candidates were the only versions, so a plain install got one; if you installed then, you have
  `1.0.0-rc.0` or `1.0.0-rc.1`, and moving to `1.0.0` changes nothing in your code.)
- They open **with test keys only**, on `localhost` and your test sites. With a live key a release
  candidate does not open (the box reports `frame_blocked`, naming the release as a thing to check),
  so your users never run a version still being tested — even if someone types its version by hand.
- No range or channel ever points at a release candidate.

## The npm packages

[@lettrove/embed](https://www.npmjs.com/package/@lettrove/embed),
[@lettrove/react](https://www.npmjs.com/package/@lettrove/react),
[@lettrove/vue](https://www.npmjs.com/package/@lettrove/vue) and
[@lettrove/node](https://www.npmjs.com/package/@lettrove/node) share **one version number** and are
published together, so `@lettrove/react@1.4.2` is built for `@lettrove/embed@1.4.2` and the editor's
`1.4` line; you never work out which goes with which. Install them at the same version. Each
package's page on npm lists every version and the tags that point at them, on its Versions tab.

| You install | You get |
|---|---|
| `@lettrove/embed` (or `@1`) | The newest 1.x. Within 1.x nothing is removed and no option changes meaning |
| `@lettrove/embed@1.4` | The newest 1.4.x: fixes only |
| `@lettrove/embed@1.4.2` | Exactly that |
| `@lettrove/embed@next` | The current release candidate, for trying what comes next; see above |

Each package carries its `CHANGELOG.md`; the [Changelog](../changelog.md) here is the same, with the
editor's releases beside it. A version that turns out to be bad is never removed from npm: it is
marked deprecated with the version to move to, and `npm install` tells you so.

## Old designs always open

A design saved by any 1.x editor opens in every later 1.x editor, unchanged. A design that holds a
block from a newer editor opens in an older one with that block kept exactly as it is.