Releases & versions

Current release

La version courante de la plateforme est publiée en lockstep sur npm public + GHCR :

Convention de tag

Chaque release est cuttée comme un tag git v<X.Y.Z> sur le repo bestraw. Le workflow Release GitHub Actions publie alors tous les artefacts en parallèle :

• npm public : bestraw@X.Y.Z + @bestraw/sdk@X.Y.Z + @bestraw/plugin-*
• GHCR npm : @lbrzr/bestraw-plugin-*@X.Y.Z
• GHCR containers : bestraw-api-{free,pro}:vX.Y.Z + bestraw-kitchen:vX.Y.Z (+ :latest mis à jour)

Le paths-filter du workflow saute la publication des artefacts dont aucun fichier source n'a bougé entre deux tags — ne sois pas surpris si une version donnée n'apparaît pas sur tous les registres en même temps.

Pin la version dans ton site

Depuis la v2.2.1, bestraw create écrit automatiquement VERSION=v<X.Y.Z> dans le .env.example généré, calé sur la version du CLI utilisé. Ne laisse jamais VERSION=latest en prod — un push GHCR pourrait silencieusement faire pull une nouvelle version au prochain docker compose pull, avec breaking changes possibles.

# .env (généré, à reporter en prod)
VERSION=v2.2.2

Le docker-compose.yml lit ${VERSION:-latest} — si tu vires la ligne, fallback latest, mais en prod c'est à éviter.

Upgrader un site existant

Depuis la v2.2.2, le CLI a une commande dédiée :

cd mon-site

# Voir ce qui est dispo vs ce que tu as
bestraw upgrade --check

# Mode interactif (picker)
bestraw upgrade

# Cible précise
bestraw upgrade --to=v2.2.2

# Avec pull + restart immédiat
bestraw upgrade --to=v2.2.2 --pull --up

La commande lit le .env (ou .env.example) du projet, valide la cible contre npm + GHCR (best-effort via docker manifest inspect), réécrit la ligne VERSION=. Pour Dokploy : bumpe VERSION dans le UI Environment tab et clique Redeploy.

Changelog complet

Le journal détaillé de chaque release vit dans le repo bestraw :

→ CHANGELOG.md → Tags releases (avec les notes inline du tag annotated)

Breaking changes — historique court

• v2.0.0 — Genericization. Tous les noms restaurant.* renommés en organization.* / catalog.*. Voir MIGRATION.md.
• v2.2.0 — Security pass. JWT_SECRET devient required-or-throw côté Strapi. Avant d'upgrader, vérifie que ton env l'a bien défini, sinon Strapi refuse de booter.
• v2.2.2 — Mem limits par défaut sur les services compose + Kitchen image rebasée sur distroless. Si ton VPS a peu de RAM, ces caps protègent contre le swap.