Skip to main content

Module releases and updates

The path of a module version from a commit to the user.

Lifecycle​

code in Git → version tag → CI test gate → package build → catalog publication
    → users see "Update" in the module store → installation
  1. Development. Module code lives in its own Git repository. The version is in module_info.php.
  2. Release. A release = version bump + tag + push. Pushing to a branch without a tag only syncs the code, nothing is published.
  3. Test gate. CI lints against the target PHP versions and runs sanity checks of the module structure. A build that fails the gate never reaches the catalog.
  4. Build and publication. The package (zip) with its file manifest lands in the update server catalog; the catalog updates the version metadata.
  5. Delivery. Installations see the new version through the catalog API; updates are applied manually from the admin panel or automatically (if the build is marked safe for auto-update).

Channels and safety​

  • Every build has an auto_ok flag: whether auto-update may install it. Risky/experimental builds are published with auto_ok=false — manual installation only.
  • The system takes a backup before applying an update; a failed update rolls back automatically.

Modules shipped with the core​

Part of the catalog ships for ECMS9 as part of the core and updates together with it — there are no separate packages for those modules. The module store marks them with the "Updated with the ECMS9 core" badge.

Release checklist​

  • Version bumped in module_info.php
  • Lint passed for all target PHP versions
  • Event listeners wrapped in try/catch and checking module_enabled()
  • No hand-edits of core configs (see Module structure)
  • Changelog written — the user sees it before updating