Jumoo Releases

Static feed of releases across Jumoo's NuGet packages, combining NuGet version/publish data with GitHub release notes (including from private repos). Published via GitHub Pages at releases.jumoo.co.uk.

How it works

• data/packages.json lists the tracked packages (NuGet package ID + GitHub repo).
• scripts/fetch-releases.mjs fetches version data from the NuGet API and release notes from the GitHub Releases API, merges them, and writes docs/releases.json and docs/feed.xml. It also writes docs/activity.json (see below).
• docs/ is a plain static site (no build step) that fetches releases.json and renders it. This is also the GitHub Pages publish directory.
• .github/workflows/update-releases.yml runs the fetch script every 6 hours (and on manual trigger), committing the regenerated JSON/feed if anything changed. Since Pages serves straight from docs/ on main, the commit itself triggers a redeploy.

Adding a package

Add an entry to data/packages.json. Its shape is described by data/packages.schema.json — .vscode/settings.json wires that schema up for autocomplete/validation in VS Code.

{
  "nugetId": "Jumoo.SomePackage",
  "aliasNugetIds": ["Jumoo.SomePackage.Old"],
  "title": "Some Package",
  "category": "Integrations",
  "githubRepo": "Jumoo/SomePackage"
}

• nugetId — the current NuGet package ID (used to build package links and as the site's canonical package key).
• aliasNugetIds — optional list of prior NuGet IDs the package has shipped under (e.g. after a rename); their version history and download counts are fetched and merged into nugetId's totals. Omit if the package has never changed ID.
• title — display name shown on the site; falls back to nugetId if omitted.
• category — groups packages into sections on the homepage (e.g. "uSync", "Integrations"); omit it to leave a package uncategorized — uncategorized packages are listed first, with no heading.
• githubRepo — owner/repo for releases, branches, and commits (the code repo).
• issuesRepo — optional owner/repo for issues and PRs, when different from githubRepo — e.g. a package whose code lives in a private repo but whose issues are tracked in a separate public *.Issues repo. Omit if issues/PRs live in githubRepo itself.

No code changes needed — the next scheduled run (or a manual workflow_dispatch) will pick it up.

Category order

By default, category sections on the homepage and versions page are ordered by whichever category had the most recent release (the uncategorized group always comes first, with no heading). To pin a specific order instead, list category names in docs/categories.json, e.g.:

["uSync Addon", "Translation Connectors", "Other"]

Categories listed there are shown in that order, before any unlisted categories (which keep the default most-recent-first behavior). It's hand-maintained (not regenerated by the fetch script) — edit it directly and commit.

Activity page

activity.html lists, per package, how many commits sit on the branch its last release was actually cut from, since that release — a quick way to spot packages that are overdue a release. Releases aren't always cut from the repo's current default branch: a package might default to an LTS branch (e.g. v17/main) while its latest tagged release shipped from a newer one (e.g. v18.0.1 off v18/main) — comparing against the wrong branch would produce a meaningless count once the two have diverged. So for each package the fetch script:

1. Fetches the most recent GitHub release (if any) and the repo's branches.
2. Finds which branch that release's tag actually sits on — the branch where the tag is a direct ancestor, picking the closest one (fewest commits ahead) if more than one qualifies.
3. Uses that branch (not necessarily the repo's default_branch) to get the commit count and last commit date.

The site flags a package with "on <branch>" next to its release when that release branch differs from the repo's current default, so it's clear at a glance when the two disagree. Packages whose repo has no GitHub release at all (no auto-release/tagging configured) are called out separately as "no tagged releases" instead of a commit count, since there's no tag to measure from.

Private repos

Release notes for private repos are fetched using a GitHub token and shown publicly on the site (repo code itself stays private — only release metadata/notes are surfaced).

Setup:

1. Create a fine-grained GitHub PAT scoped to Contents: read on the private repos listed in data/packages.json.
2. Add it as a repository secret named RELEASES_GH_TOKEN (Settings → Secrets and variables → Actions).

Local development

npm install

# Fetch latest release data (requires a GH token env var for private repos)
GH_TOKEN=ghp_xxx npm run fetch

# Serve the site locally at http://localhost:4173
npm run dev

GitHub Pages setup

1. Repo Settings → Pages → Source: main branch, /docs folder.
2. docs/CNAME already contains releases.jumoo.co.uk — add a DNS CNAME record at your DNS provider pointing releases.jumoo.co.uk to the org's github.io Pages domain.