> Lettrove docs 1.x · https://docs.lettrove.com/docs/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.
- 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`, `@lettrove/react`, `@lettrove/vue` and `@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.

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