Versioning and support

Two numbers matter when you run Railbase: the version of the core binary on your server, and the version of each plugin installed into it. This page explains what those numbers mean, how often they move, and what you can rely on.

How versions are numbered

Railbase uses MAJOR.MINOR.PATCH — for example 0.20.12. Today the core is pre-1.0 (0.y.z), and that is deliberate: the product is under daily development.

While pre-1.0:

• a breaking change raises the MINOR number (0.20.x → 0.21.0);
• everything else — features, fixes, performance — raises the PATCH number.

Read that honestly: pre-1.0 means interfaces can still move between minor versions. What protects a running install is not a promise, it is the compatibility gate described below, plus the fact that an update takes a backup and rolls itself back if the new binary doesn't come up healthy.

How often a new version appears

Core releases are batched daily — a day's work ships as one version rather than a release per change. A security fix does not wait for that batch: it ships the same day as its own release and is marked as a security release on the changelog.

Plugins are versioned and released independently of the core. A plugin's page shows the version currently published.

Which versions get fixes

Fixes land in the newest release. There is no long-term-support line, no back-porting to older versions, and no end-of-life calendar — the supported version is the current one.

That is a real constraint, so it is worth stating plainly rather than implying a support matrix we do not operate: if you stay several versions behind, the way to get a fix is to update.

Plugin ↔ core compatibility

Every plugin declares the minimum core version it needs, and the marketplace refuses to install it on anything older — which is why each plugin's page shows a "needs core ≥ X" requirement.

This is the gate that makes a pre-1.0 platform safe to run: a plugin that assumes a capability your core doesn't have will not install at all, rather than installing and failing at the worst moment.

If an install is refused for this reason, update the core first, then the plugin — see Updating.

Updating safely

The core updates itself in place, and the sequence is built to be survivable:

1. it takes a snapshot of your Vault before touching anything;
2. it stages the new binary and dry-runs the migrations;
3. it swaps, then health-checks — and rolls back automatically if the new version doesn't come up.

Recommended order: snapshot → core → plugins. Details in Updating and Backups and restore.

Where to read what changed

• Changelog — every core release with its notes.
• Your admin's Update Center — the same notes, next to the update button, so you can read what you are about to install.

The legal ceiling

Worth knowing before you plan around it: the free core carries no obligation on us to provide updates, fixes or support, and a plugin's compatibility with future core versions is commercially reasonable effort rather than a guarantee. A retired plugin stays licensed for the term you paid, but stops receiving updates.

Those limits are written in the EULA and the Plugin Subscription Agreement, and summarised on the legal overview.

Questions

Is Railbase production-ready before 1.0?

It runs production workloads today, and the update path is built to be reversible. What pre-1.0 signals is pace of change, not fragility: expect interfaces to keep moving, and keep your instance current rather than pinning it and hoping.

Do I have to update?

No — a core keeps running at its current version, and a paid plugin keeps working for its term. But fixes only land in the newest release, so an old instance accumulates known issues that are already fixed elsewhere.

What happens if I install a plugin on too old a core?

The install is refused with the minimum version it needs. Nothing is half-installed; update the core and try again.

How do I know which version I'm on?

Your admin shows the core version in the Marketplace and in the Update Center; the same number appears in the binary's --version output.