# Upgrading Kaabe

```bash
cd ~/kaabe
bash scripts/upgrade.sh ~/kaabe-saas-<new-version>.zip
```

The script does the following, in order:
1. **Backup:** runs `scripts/backup-all.sh`.
2. **Maintenance mode** for the Super Admin.
3. **Keeps the running release** in `~/kaabe-previous-<timestamp>` for rollback.
4. **Unpacks the new code** over the old. `.env` files, `storage/` and the registry are kept.
5. **Rebuilds** the PHP libraries.
6. **Central database:** runs `php artisan migrate --force` and rebuilds the caches.
7. **Business databases:** runs `php artisan kaabe:tenants-migrate` on every business database. These changes are additive only.
8. **Ends** maintenance mode.

**If the new version misbehaves**, roll back:

```bash
bash ~/kaabe/scripts/rollback-release.sh ~/kaabe-previous-<timestamp>
```

This restores the previous code. If the upgrade changed a database, restore the backup made in step 1 (`BACKUP-RESTORE.md` §3).

**Before every upgrade,** read `CHANGELOG.md` for changes that need action.

## Tested notes (1.0.0)
- The ZIP contains `platform/vendor`; `upgrade.sh` replaces it as a whole and never needs Composer or internet access.
- `upgrade.sh` keeps `.env` files, `platform/storage`, the tenant registry and backups; it takes a backup first and keeps the previous release in `~/kaabe-previous-<timestamp>`.
- If `upgrade.sh` stops with an error, the Super Admin stays in maintenance mode on purpose: run `bash scripts/rollback-release.sh ~/kaabe-previous-<timestamp>` (and restore the database backup if migrations had run), or fix the cause and run `php artisan up`.
- The POS keeps working during an upgrade; business databases are migrated by `php artisan kaabe:tenants-migrate` (called by the script).