Release Notes and Versioning
This page summarizes how the Wayland Core engine ships. The authoritative sources are CHANGELOG.md and RELEASING.md in the engine repository.
Versioning
Section titled “Versioning”The engine follows semantic versioning. Each release records its changes in CHANGELOG.md, so you can see what is new, changed, and fixed between any two versions.
How a release is built
Section titled “How a release is built”Releases go out through CI. On the happy path, cutting a release tag triggers the pipeline, which builds and packages the binaries and publishes the release. When CI is green but packaging needs a re-run, a manual dispatch repeats the packaging step against the existing tag.
The binary matrix
Section titled “The binary matrix”A release publishes the engine for each supported platform and architecture: macOS, Linux, and Windows across the relevant CPU architectures. The npm package @ferroxlabs/wayland-core is a launcher plus per-platform binary packages, so installing it pulls only the binary that matches your machine.
Signed releases
Section titled “Signed releases”Each release artifact is signed. The signature (ed25519) is what lets the engine confirm a build is authentic before trusting it. This is the same check that protects updates.
Self-update
Section titled “Self-update”The engine updates itself from its signed release feed:
wayland-core self-update # update to the latest signed releasewayland-core self-update --check-only # print current vs. latest, do not installself-update verifies the artifact’s signature against a pinned key, then swaps the binary in place atomically. If the signature does not verify, the update does not proceed.
Verifying a release yourself
Section titled “Verifying a release yourself”You can verify a downloaded artifact against its published signature before running it. See RELEASING.md for the exact verification steps.