Skip to main content
Every product and element_sdk is published as numbered releases. This page explains the numbers, how a product says which element_sdk it works with, and every message you see when the two do not match.

Reading a version number

A version has three parts, for example 1.4.2: Below 1.0.0, the second part plays the role of the first: treat a change from 0.1 to 0.2 as one that may need action. A version with a suffix, such as 1.1.0-beta.1, is a pre-release. A pre-release is older than the same version without the suffix: 1.1.0-beta.1 comes before 1.1.0. Where to find a version: the version line in the resource’s fxmanifest.lua.

Stable and test releases

At every start your server compares each installed Element Labs resource with the releases on the channel that matches it: a pre-release is compared with candidates, a normal release with stable ones. You can change that, or silence the notice, with el:versionChannel. See Server settings.

Which element_sdk a product accepts

A product accepts a range of element_sdk versions, not one exact version, so an element_sdk update inside that range needs nothing else from you. The range is in the release’s INSTALL.md, and in the product’s fxmanifest.lua:
So ^0.1.0 accepts 0.1.0 and every 0.1.x after it, and nothing from 0.2.0 on. When you update, update element_sdk first. A newer element_sdk inside every product’s range keeps all of them working; a newer product may need a newer element_sdk.

When the versions do not match

The product checks element_sdk when it starts. If the check fails, it prints the reason, then one line naming itself, and stops a moment after starting:
The product stops rather than running on an element_sdk it was not built for, which would fail later in ways that are much harder to trace. Always act on the first line. All lines but the last start with [ERROR] [Dependencies]; the last with [WARN ] [Dependencies]. The check can be turned off with el:dependencyCheck to confirm a diagnosis. See Server settings.