Version Management
RUAL Core versions, stable vs development releases, how to upgrade safely, and where breaking changes live.
RUAL Core evolves continuously. Clusters run on a specific core version, and you choose when to move to a newer one. This guide explains the release model and a safe upgrade routine. The full per-version history lives in Core versions.
Release Channels
| Channel | What it is | Who should run it |
|---|---|---|
| Latest stable (latest) | The current production-ready core. Receives only fixes and compatible improvements. | Production clusters, always. |
| Development (development) | The next core in progress. New blocks and changes land here first and may still shift. | Test clusters, early adopters, preparing for the next stable. |
| Older stables | Previous stable lines, kept for reference in the release notes. | Clusters mid-migration. |
Version numbers read as major.minor.patch (e.g. 14.0.3): majors and minors bring new blocks and behavior, patches bring fixes. The sidebar's version card always shows the latest stable.
A Safe Upgrade Routine
- Read the release notes for every version between yours and the target — see Core versions. Focus on "new and changed blocks" and anything marked deprecated.
- Check your blueprints for affected blocks — in RUAL Studio, the Deprecated Actions view lists blocks in your cluster that changed behavior or are deprecated.
- Upgrade a copy first — test on a development cluster or during a low-traffic window. Your blueprints, documents, and settings carry over; the runtime changes underneath them.
- Smoke-test the critical paths: your pages, your busiest APIs, sign-in, and any integrations (tokens, webhooks, email).
- Watch the logs for the first hours after upgrading (Studio → All Logs).
Breaking Changes & Deprecations
Breaking changes are rare and always documented in the version's release notes — look for warning callouts at the top of a version page (for example, an API being replaced or a property renamed). Deprecated blocks keep working for a long time; the block page for a deprecated block shows the version it was deprecated in and usually its successor. Migration steps, when needed, are written into the same notes.
Which Version Should You Use?
- New cluster, production — latest stable. There is no reason to start older.
- Running production — latest stable, on your own schedule. Read the notes before each jump.
- Evaluating an upcoming feature — a development core on a test cluster, never on customer-facing production.
- Enterprise Cloud — upgrades are coordinated with RUAL support on a schedule that fits your SLAs.