Changelog and versioning
What changed, and what we promise not to change under you.
What is versioned
Three things move independently, on purpose.
| Thing | Version | Where you see it |
|---|---|---|
| Wire protocol | RDUI/1 | client.protocol on every chat request |
| Component catalog | A date-stamped string, e.g. 2026-09.a | client.catalog_version |
| Flutter SDK | Semantic version, e.g. 0.1.0 | client.sdk as flutter/0.1.0 |
The promises
The protocol version changes only for a break. Inside RDUI/1, we may add event types, add fields to existing events, and add error codes. We will not remove a field, change a field's type, or change what an existing event means. An SDK that skips events it does not recognise — which the Flutter SDK does — keeps working across every additive change.
The catalog only grows. A component in the catalog stays in the catalog, and its props stay valid. New props are optional. New components are announced by your client.components list, so a build that has never heard of a component is never offered one: the model's toolset is the intersection of its catalog and yours, computed per request.
The SDK follows semver. Before 1.0.0, a minor bump may break: we are still moving the public API, and we would rather do that now than carry a mistake to the first stable release. Every break is in this file with the line to change.
Nothing is removed without a deprecation period. Once we are past 1.0.0, a deprecated API keeps working for at least one minor release and logs through NCConfig.onLog with the code deprecated.
Minimum SDK version
The server can refuse a build below a floor, per platform, with the error upgrade_required. It is empty today and will stay empty unless a protocol break makes an old client actively wrong — at which point the alternative is that build failing in a way nobody can explain to its user.
Releases
The most recent are here. Every Flutter version, with the edit any break asks
of you, is in the package's own CHANGELOG.md, next to the code you install.
Flutter 0.34.0 · Web 0.11.0
Answers are pages. Each question opens a page of its own instead of adding a turn to a thread: the question is written over the screen as it is asked, never as a bubble, the screen gives way, and the answer is drawn from the top as one composition. It opens with the answer in a sentence, the phrase that matters highlighted; then sections that support it; a short verdict where one option was picked over others; and, at the foot, whole questions to go on with. Back and forward move between the pages a conversation has opened.
While a turn runs, a pill in the microphone's place says what is happening: thinking, checking your app, putting it together.
This is the default on both SDKs from these versions. answerPages: false
keeps the thread exactly as it was. Two components arrive with it,
section and
key_points; a build that does not
declare them is never offered them.
Flutter 0.33.0 · Web 0.10.0
Keys made in the console now start rd_pk_, and the SDKs send their key,
device and the person's token as X-Rendel-Key, X-Rendel-Device and
X-Rendel-User-Token. A key that starts nc_pk_ keeps working everywhere,
and the API reads the old X-NC- headers as well, so a build already shipped
does not need to change.
A new rd_pk_ key needs Flutter 0.33.0 or Web 0.10.0: an older build checks
the prefix itself and refuses the key at init. If you create or rotate a
key, update the SDK in the same release.
Flutter 0.32.0 · Web 0.9.0
The SDKs are Rendel's by name. On Flutter the package is rendel, at
sdk/flutter/rendel: rename the dependency and its path, and import
package:rendel/rendel.dart (Install the SDK has the block).
NeonCopilot is Rendel, and the NC and Copilot types are Rendel types
(RendelConfig, RendelTheme.paper()). On the web the global is Rendel and
the file is rendel.js.
The old names keep working on both, marked deprecated: on Flutter as aliases
of the new types, on the web as window.NeonCopilot, the same object, and
neon-copilot.js beside rendel.js in 0.9.0. They go at 1.0.
Flutter 0.31.0 · Web 0.8.0
The soft-glass blocks. Every block is drawn in the finish the component gallery shows: a glass plate, grouped rows in one white panel, a lit primary button, no grey boxes. A form is one panel of rows with a glyph for each kind of field; the order tracker is a line of soft marks with the current step named beside the title; a bar chart leads with its latest value. Text contrast is unchanged.
Flat cards are now the default on both platforms. The raised and outlined styles are still drawn when a theme asks for them.
Both SDKs now talk to https://api.rendel.ai by default. The old address
keeps answering, so a build already shipped does not need to change.
Flutter 0.30.0
One answer to a screen. NCConfig.answerPages gives each answer a page of
its own instead of a place in a thread: a question clears what is on screen,
the answer is drawn from the top, and the answers before it are a step back
through the arrows in the header. Off by default, and nothing about what is
sent or kept changes with it — every turn is still written down, and the
console shows the whole thread whichever way the app drew it.
Such a build declares answer_pages, and the copilot then closes a
substantial answer with two or three whole questions to go on with, drawn as
cards at the foot of the page. To a build that does not, quick replies stay
pills in a row.
Flutter 0.29.0 · Web 0.7.0
Blocks replace themselves. The copilot can name something on screen that will change (a cart, an order, a set of slots) and draw it again as it changes; the new drawing takes the old one's place instead of a second one appearing beside it. A choice the person made stays while the new drawing still offers it. An older drawing that arrives late is dropped. See Screens that update in place.
pair(code) pairs a test build with the console's Test page, which then
watches that build's conversation for two hours. Test keys only. See
Pair a test app.
Flutter 0.28.0 · Web 0.6.0
Forms update in place. When the copilot redraws a form the person has not sent yet ("make it a refund to my card"), the new form takes the old one's place and keeps every answer they gave for a field that is still there; a field they changed themselves keeps their value. Each message also tells the copilot what is in the open forms, so it answers knowing what was already chosen. Nothing to wire. A build before these keeps drawing a redrawn form as a second form.
Flutter 0.27.0 · Web 0.5.0
Console actions that change something — "book me in on Tuesday", "cancel my
order" — when the endpoint is set to the signed-in user's token. The copilot
asks the person on a confirmation card first, as it does for your own write
actions; once they confirm, Rendel makes the call itself, as them, and
answers with what happened. Nothing to register and nothing to wire: it needs
only the token, NCConfig.userToken on Flutter or NeonCopilot.setUserToken
on the web, which arrived in Flutter 0.26.0 and Web 0.4.0. An older build
answers a confirmed card of this kind with an error, and nothing changes.
0.1.0 — unreleased
The first version. Nothing to migrate from.
The Flutter package is not on pub.dev yet; it is installed from a git reference (Install the SDK). What is in it:
- 21 components, all drawn natively
- Actions with three risk levels and server-enforced confirmation
- Remote appearance config with a device-side legibility floor
- Identity binding with optional HMAC verification
- Structured logging through
NCConfig.onLog - Per-turn ratings
Known gaps, all of them tracked:
- No history convergence after a dropped stream — a lost frame is skipped, not re-fetched
- Knowledge retrieval falls back to text matching until embeddings are configured for your app
- No self-serve bulk export; ask and we produce one within five working days
How you will hear about a change
Breaking changes are emailed to every member of every organization with a live key, at least two weeks ahead. Additive changes appear here. There is no in-product changelog feed yet.