# prod / dev release workflow — Android (MAUI APK)

Status: design only. Same intent as `prod.md` (npm side); the APK is a complete, self-contained binary so the unit of promotion is a *file*, not a dependency or dist-tag.

## Simpler approach (Bob 2026-05-09)

No separate MAUI project. Same source tree produces both flavors; the difference is purely in the OUTPUT filename, and "what's currently prod" is decided by which file lives at the canonical prod URL.

### Today

- One build target: `mailx-maui.apk` at `https://rmf39.aaz.lt/mailx/mailx-maui.apk`.
- `versions.json` carries the version string; updater compares to running.
- Every build overwrites the single APK. No history, no channels.

### Phase 1 — start producing dev.apk too

While there's no formal "production release" yet, every build produces:

- `rmfmaildev.apk` (or `dev.apk`) — the just-built, latest dev tip. Updater on dev devices points here.
- `mailx-maui.apk` — unchanged for now (current production behavior). Updater on prod devices points here.

The build script writes both. Same APK contents initially — the dual output is just renamed copies. Devices on different channels read different filenames.

### Phase 2 — once a release is declared

Build outputs:

- `rmfmaildev.apk` — every build. Always the freshest.
- `rmfmail-<version>.apk` — versioned filename, never overwritten. One file per build.

"Promoting" a known-good dev build to production = `cp rmfmail-1.0.NNN.apk rmfmail.apk` (or web-server-side: update a redirect / symlink / manifest pointer at `rmfmail.apk` to name the chosen versioned file).

The canonical URLs:

```
https://rmf39.aaz.lt/mailx/rmfmail.apk           ← prod pointer (chosen versioned APK)
https://rmf39.aaz.lt/mailx/rmfmaildev.apk        ← latest dev build
https://rmf39.aaz.lt/mailx/rmfmail-1.0.NNN.apk   ← every released version, immutable
```

Roll back = re-point `rmfmail.apk` to a prior versioned APK.

## What changes from the current build

`build-apk.cmd` / `build-apk.ts`:

- Read version from `package.json` (already does).
- Build APK once.
- Phase 1: write to `rmfmaildev.apk` AND `mailx-maui.apk` (mirror).
- Phase 2: write to `rmfmail-<version>.apk` (versioned, never overwritten) AND `rmfmaildev.apk` (latest dev mirror).
- Sync to web root.

Promotion script (`prod-android.ps1`?) — Phase 2 only:

- Take a version arg (or default to current dev build).
- Copy / point `rmfmail.apk` at that version's APK.
- Update `versions.json` so the updater on prod devices sees a newer version available.

`AppUpdater.cs` — channel awareness:

- Reads from configurable URL based on channel setting.
- Default: prod URL (`rmfmail.apk` / corresponding `versions.json`).
- Dev mode: dev URL.
- Channel toggle in Settings (or build-time constant in a separate flavor — but per Bob's preference, NO separate MAUI project; channel is a runtime setting).

## What this does NOT need

- **No separate MAUI project**. The APK is the same binary regardless of which channel it serves; users with the dev URL configured get latest builds, users with the prod URL get whatever was last promoted. Source tree is single.
- **No dist-tag analog**. The "tag" is just the filename / URL the updater polls.
- **No flavor build**. Same package id, same signing key, same APK bytes — just two distribution endpoints (or, with Phase 2, two distinct files referenced from the manifests).

## Coexistence on a single device

Single MAUI project means a single Android package id. Two builds CAN'T be installed side-by-side without diverging package ids (Android refuses). If side-by-side becomes a real need later, reintroduce the separate-MAUI-project idea — but that's the orthogonal "I want both versions on the same phone" design, not the prod/dev release flow.

## Order

1. **Phase 1 first**: build script outputs `rmfmaildev.apk` alongside today's `mailx-maui.apk`. Zero behavior change for prod users; dev users (on the dev channel) get latest. ~10 lines in `build-apk.ts`.
2. **AppUpdater channel toggle**: Settings checkbox + persisted preference + URL switch. ~50 lines.
3. **Phase 2 when ready**: switch to versioned filenames + `rmfmail.apk` pointer + promotion script. Done when there's a real first "production release" to designate.

## Effort

- Phase 1: ~30 minutes (build script + manifest output).
- AppUpdater channel: ~1 hour (Settings UI + storage + URL plumbing).
- Phase 2: ~1 hour when activated (promotion script + versioned filenames + pointer mechanism on web root).

Total ~2.5 hours wall-clock when fully wired. Phase 1 alone gets you the "always-have-a-fresh-dev-build" benefit without any commitment to the formal release flow.
