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

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, @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. 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 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.