Skip to content

Update modes on the server: automatic, pinned, approve first #755

Closed

Description

@keyxmakerx

First slice of #685. Build the data and service behind the signed update-flow mockup (sign-off page, card "ui-685", version 3, approved 2026-09-25).

  • One mode for every package: automatic, pinned (with a version), or approve first. It applies per package (admin) and per campaign (owner), for game-system packages and the Foundry module alike.
  • The Foundry module's existing settings map onto it.
    • A pin maps to pinned.
    • The stored preserve pin mode maps to pinned.
    • An empty mode or promote maps to automatic.
    • A package with auto-update off and no pin becomes pinned to its current version (approved default).
  • Approve first holds a newly installed version for that campaign until the owner or an admin approves it. An admin's "approve on their behalf" uses the existing force-pin action.
  • Game systems gain what Foundry pins already have:
    • a per-campaign version;
    • install-time auto-pin;
    • cleanup protection for any version a campaign is pinned to.
  • Cleanup stays as it is otherwise: game systems only, never Foundry module versions.
  • The auto-update check cadence (off, nightly, weekly, on release) stays the checking schedule under automatic and approve first.
  • No current function is lost. The mockup's "Everything today's screens do" list is the checklist.

Migrations are append-only and idempotent. Existing rows are carried over by an idempotent reconciler, not by a data migration.

Activity

  1. keyxmakerx commented on Oct 3, 2026

    @keyxmakerx
    OwnerAuthor

    Key Maker approved the updated screens (Sign-offs card mock-update-modes, version 1, 3 October) with plain labels: Automatic, Stay on a version, Ask me first (stored values can stay automatic / pinned / approve_first). Owners choose per package on Manage › Apps & game system (new Updates card); the Foundry setup guide links there; the admin Packages side panel Campaigns tab shows each campaign's choice and version with Move, Remind owner and Approve for them. Building the server slice first (no visible change), then the screens.


    Generated by Claude Code

  2. keyxmakerx commented on Oct 4, 2026

    @keyxmakerx
    OwnerAuthor

    Paused for usage (operator request). State:

    • Done, not pushed: the per-campaign update work is built and reviewed. It includes the automatic old-version clean-up (packages migration 005), the server side for per-campaign updates (migration 006), and the approved "owners are asked" screens for the Foundry module (Update / Later on the campaign home, a row on Apps & game system with Use another version, and admin Hold / Move / Remind on Packages > Campaigns). The reviewer and migration-safety checks found no blocking issues.
    • Where it is: a git bundle in the project files (admin/admin-held-commits.bundle, head stack-held). It sits on top of Validate the pinned Foundry module version #976 and needs a rebase onto main before it can be opened as a PR.
    • Next: merge Validate the pinned Foundry module version #976, rebase the bundle onto main, run the full verify, then open one PR. Game systems follow after Serve each campaign its own game-system version #963.

    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions