All posts
Release Notes · 2 min read

Aether v0.1.0: version reporting and engine channels

The first release wires a build identity through the app and world servers, lets a GM move one world to another engine, and adds checks around world data and deployment.

Aether Team
Aether Team
The team

v0.1.0 is where Aether starts keeping track of itself. It gives a GM a way to try another engine on one world, and gives the server enough information to stop an unsafe rollback.

Engine channels

A GM can put one world on an early-access engine while the other worlds stay on the current one. The switch stops that world, saves a copy, checks the copy, and then changes its engine.

The awkward bit is the trip back. A newer engine may save something the current engine cannot read. In that case, keep using the newer engine or go back to the copy from before the switch. That copy does not include the sessions played since then. The web app, gateway and Aether app stay on the latest version.

The world has a data version now, too. A world from before v0.1.0 is accepted when it opens. If an older engine finds a newer version, it refuses to open the world and reports both versions. There is no forward migration here yet. We can add one when the data actually changes.

Existing worlds and release checks

Before this release, a world kept the settings it was created with. When it wakes now, the server can tell whether those settings are stale. A running table is not interrupted. For always-warm worlds, recreate-worlds shows what would change before it does anything. Applying it drops the table's connections, so the command defaults to a dry run.

The tag gate and the smoke test are the other half. CI must have a successful run for the exact commit. The smoke test then creates a world, wakes it, opens a WebSocket through Caddy and the gateway, checks the version, and deletes the world. That would have caught v0.0.10, which kept returning HTTP 200 while world creation was broken.

Keep reading