Skip to content

Define the maintainer handoff: release bundle layout and merge step #17

Closed

Description

@JMAN730

Part of #12

Question

What exactly does the site maintainer receive on each release, and how do they get it onto repo.redwizard.xyz with the least friction?

The maintainer manages ~28 third-party addons this repo doesn't build, so the bundle must splice into an existing server tree, not replace it. Decide:

  • Bundle shape: one zip per channel mirroring the server layout? A single tarball plus a merge script?
  • The merge step: hand-written instructions, or a small script shipped in the bundle that regenerates the merged addons.xml + .md5 server-side?
  • Where the handoff doc lives (docs/RELEASING.md?) and what it says.

Blocked by the build-script prototype (the bundle shape falls out of it).

Deliverable: the decided handoff design in the resolution comment; the doc itself can land with the release workflow.

Activity

  1. self-assigned this
    on Jul 6, 2026
  2. JMAN730 commented on Jul 6, 2026

    @JMAN730
    OwnerAuthor

    Resolved. The handoff design:

    • Merge problem (server carries ~28 third-party addons our addons.xml doesn't): the bundle ships a stdlib-only merge_addons.py. It takes the server's current addons.xml plus our partial one, replaces/inserts repo-owned <addon> entries by id, leaves every third-party entry untouched, and rewrites addons.xml + .md5. No hand-edited XML, no hand-computed hashes.
    • Release asset shape: one zip per channel — redwizard-repo-<channel>-<tag>.zip — each unpacking directly over the matching server channel directory (per-addon folders with zips and art, plus our partial index under the non-clobbering name addons.repo-owned.xml), with merge_addons.py attached as a separate asset. A single-addon bump means the maintainer downloads one channel zip, not everything.
    • Maintainer workflow ends up: download changed channel zip(s) + merge script → unpack over server staging dir → python3 merge_addons.py <server addons.xml> <addons.repo-owned.xml> per channel → upload.
    • Doc: docs/RELEASING.md, covering both audiences — contributors (bump versions, tag v*, CI builds; one-time workflow token scope note) and the site maintainer (the four steps above), plus a pointer that upload automation / GitHub Pages hosting remains open if the maintainer ever wants it. The doc and script land with the release-wiring ticket.
  3. JMAN730 commented on Jul 6, 2026

    @JMAN730
    OwnerAuthor

    Closing — handoff design decided, see resolution above.

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

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions