Versions and support

Sandly follows Semantic Versioning: MAJOR.MINOR.PATCH.

• Patch (1.4.1 → 1.4.2): fixes only.
• Minor (1.4 → 1.5): new features. Everything that worked keeps working, and the database stays usable by 1.4.
• Major (1.x → 2.0): may remove or change things incompatibly, including in the database. Its release notes say what to do.

The account menu shows which version is running.

What’s supported

• The current and the previous minor version get fixes, as patch releases: with 1.5 out, 1.5.x and 1.4.x.
• Upgrades go from any version to any later one of the same major version directly (1.2 → 1.5). Across major versions, one at a time: the latest 1.x first, then 2.0.
• Going back one minor version works on the upgraded database without a restore (1.5 → 1.4), in case a new version misbehaves. Further back, Sandly refuses to start and says what can run: restore the backup taken before the upgrade instead.

Sandly checks this itself at startup, against every version that has run on the database.

To follow a minor version’s fixes automatically, use its short tag in SANDLY_IMAGE (…/sandly:1.5): every docker compose pull then brings its latest patch. How to upgrade is in the guide.

Update notices

Sandly never calls out on its own. If you’d like to hear about new versions, set UPDATE_CHECK_URL in .env to your vendor’s release feed: Sandly checks it once a day, sending nothing about your installation, and admins see “Sandly 1.6.0 is available” in the account menu.