# Archipelago Release Process

## Overview

Archipelago uses a JSON-based release manifest for the auto-update system. The backend checks `UPDATE_MANIFEST_URL` periodically (based on user's schedule setting) and compares versions.

## Manifest Format

The manifest is a single JSON file at:
```
https://raw.githubusercontent.com/archipelago-os/releases/main/manifest.json
```

```json
{
  "version": "0.2.0",
  "release_date": "2026-04-01",
  "changelog": [
    "Added automatic update scheduling",
    "Improved backup encryption"
  ],
  "components": [
    {
      "name": "archipelago",
      "current_version": "0.1.0",
      "new_version": "0.2.0",
      "download_url": "https://github.com/archipelago-os/releases/releases/download/v0.2.0/archipelago",
      "sha256": "abc123...",
      "size_bytes": 15000000
    }
  ]
}
```

## Release Steps

### 1. Build Release Artifacts

On the build server (192.168.1.228):

```bash
# Build backend (release mode)
cd ~/archy/core
cargo build --release -p archipelago

# Build frontend
cd ~/archy/neode-ui
npm run build
```

### 2. Generate Manifest

```bash
./scripts/create-release-manifest.sh \
  --version 0.2.0 \
  --date 2026-04-01
```

This auto-detects the backend binary and frontend archive, computes SHA256 hashes, and writes `manifest.json`.

### 3. Upload Artifacts

Upload the backend binary and frontend archive to GitHub Releases:

```bash
gh release create v0.2.0 \
  core/target/release/archipelago \
  /tmp/archipelago-frontend-0.2.0.tar.gz \
  --title "v0.2.0" \
  --notes "See CHANGELOG.md for details"
```

### 4. Publish Manifest

Push the generated `manifest.json` to the releases repo:

```bash
# In the archipelago-os/releases repo
cp manifest.json .
git add manifest.json
git commit -m "Release v0.2.0"
git push
```

### 5. Tag the Source

```bash
git tag v0.2.0
git push --tags
```

## Update Schedules

Users can configure how updates are handled:

| Schedule | Behavior |
|----------|----------|
| **Manual** | Never checks automatically. User must click "Check for Updates" |
| **Daily Check** (default) | Checks once per day. Notifies user, who decides when to install |
| **Auto-Apply** | Checks daily. Downloads and applies at 3 AM, restarts service |

## Rollback

If an update causes issues, users can rollback from the System Update page. The previous binary is backed up to `{data_dir}/update-backup/` before applying.

## Security

- All downloads are verified against SHA256 hashes in the manifest
- The manifest itself is fetched over HTTPS from a known URL
- Binary replacement requires service restart (handled by systemd)
- Rollback is always available after an update