Etusivu Tutki Apua
Kirjaudu sisään
Medowar
/
manager
1
0
Haarauta 0
Tiedostot Esitykset 0 Vetopyynnöt 0 Wiki
Puu: d2870b6772
Haarat Tunnisteet
manager
/
docs
/
RELEASING.md

RELEASING.md 3.5 KB
Historia Raaka

Publishing Releases

Overview

A release is a ZIP whose root is the project's application root. The client rolls it out over the existing installation.

Flow: build → upload → set as current → instances fetch it.

1. Build the package

client-package/scripts/create-release-zip.sh is the template. It ships with the client package, gets adjusted once per project (product name, version file, exclusion list), gets copied into the project, and is run there:

./scripts/create-release-zip.sh v1.3.0

The script

  1. writes the version into the version file,
  2. verifies that the write actually took effect,
  3. packs every file tracked by Git, minus the exclusion list,
  4. prints file count, size and SHA-256.

It warns if the working copy has uncommitted changes: since the file list comes from git ls-files, uncommitted changes would otherwise silently be left out of the package.

Details — package layout, exclusions, common mistakes: ../client-package/docs/06_UPDATE_PACKAGING.md.

2. Upload

Open Releases, enter a version in vX.Y.Z format, choose the ZIP, upload.

The server

  • checks the file's extension and ZIP signature,
  • stores it as <MANAGE_PACKAGE_PREFIX>-<version>.zip,
  • computes SHA-256 and size itself and records them in the manifest,
  • sets the release as current.

The checksum shown should match the one from the build script. If it doesn't, a different file was uploaded.

If the upload fails for no apparent reason, the PHP upload limit is usually smaller than the package. The current values are shown on the Releases page and under Settings → Diagnostics.

3. Choose the current release

An upload automatically sets the new release as current. Set as current can select a different one at any time — this is also the way to point back at the previous version after a botched release.

Important: this only changes what instances download from now on. Already deployed instances stay where they are — the client has no rollback. Bringing an instance back to an older version means rolling it out again with update --force; that does not undo data changes made by migrations.

4. Deploy

On the instance:

php manage-client/bin/manage-client.php check     # exit 2 = update available
php manage-client/bin/manage-client.php backup    # back up first
php manage-client/bin/manage-client.php update

Or via the UI in the project's admin area.

Updates don't run automatically. They overwrite files while the application is live and can trigger migrations; that belongs under supervision.

Deleting a release

Delete removes the manifest entry and the ZIP file. If it was the current release, the server then has none — instances report Es ist kein gültiges Release veröffentlicht ("no valid release is published" — the literal, still German, API text). Set another one as current first.

Version numbers

Format vX.Y.Z, nothing else. Both client and server reject anything else. Re-uploading an already-published version overwrites the package — for a broken release, a new patch version is the cleaner choice, because otherwise instances end up with different installs depending on when they updated.

Next