Goal
Register RIGStats on Softpedia and keep the listing up to date with every new release.
PAD file (recommended submission method)
A PAD (Portable Application Description) file is now maintained at:
https://rigstats.app/pad.xml
Softpedia's submit form (see below) has a dedicated "Use this form if you have a PAD file" section that only needs the PAD URL + contact email — Softpedia parses everything else (version, description, OS support, download URL, file size) straight out of the XML.
Installer filename — important note
The release pipeline produces RIGStats_{version}_x64-setup.exe (version number baked into the filename). This means direct links to a specific file (/releases/download/v1.35.2/RIGStats_1.35.2_x64-setup.exe) become stale after the next release — see the Automation section below for how website/pad.xml stays in sync.
Download Page URL for Softpedia (always current, used as a fallback field):
https://github.com/dvalfrid/rigstats/releases/latest
One-time submission — DONE
Description text (embedded in the PAD file, kept here for reference)
RIGStats is a lightweight, open-source hardware monitoring dashboard for Windows.
It displays real-time telemetry for your entire rig — CPU, GPU, RAM, storage,
network and system power — in a clean, always-visible overlay.
Features: CPU/GPU/RAM/disk/network/power panels with sparklines, portrait and
landscape profiles, desktop wallpaper mode (WorkerW), floating overlay, Fill
Screen mode for dedicated monitors, built-in auto-updater, and a bundled
sensor service powered by LibreHardwareMonitor.
Requires Windows 10 or 11 (64-bit). Free and open source.
Per release — update Softpedia (automated)
website/pad.xml now keeps itself in sync automatically across two mechanisms, both landing inside release-please's own release PR (so everything flows through the normal branch-protected merge — no privileged token, no direct push to main):
- Version + download URL:
Program_Version and Primary_Download_URL are marked with the same x-release-please-version marker comment used in src-egui/Cargo.toml, and website/pad.xml is registered in release-please-config.json's extra-files. Release-please bumps both directly whenever it opens/updates the release PR.
- Release date + changelog text:
Program_Release_Month/Day/Year and Program_Change_Info can't be set by a simple version-substring bump, so release-please.yml has an extra step that reads the newest entry release-please just wrote into CHANGELOG.md (same PR), extracts the date and the bug-fix/feature bullets (stripped of markdown links, joined as "scope: subject; scope: subject"), and pushes a follow-up commit with those PAD fields onto release-please's PR branch (release-please--branches--main). That branch isn't protected the way main is, so this works with the default GITHUB_TOKEN — no bypass needed.
End to end: merging the release PR (normal flow, same as any other release) lands the version, download URL, date, and changelog text together on main. deploy-website.yml republishes website/pad.xml to https://rigstats.app/pad.xml automatically. Softpedia (and other PAD-aware directories) periodically re-crawl the saved PAD URL and pick up the change on their own — no manual re-submission needed.
Not auto-updated (left as-is from the initial submission, cosmetic/low-stakes): File_Size_Bytes/K/MB. This needs the actual compiled installer, which only exists after the release PR is merged and release.yml builds it — by then we're back to the branch-protection problem. Not worth a privileged PAT just for a size figure that only drifts by a few KB per release; revisit only if a directory actually rejects updates over it.
Why not push directly from release.yml?
Originally tried updating website/pad.xml from a post-build step in release.yml (after the installer is built, so exact file size is known) and pushing straight to main. This was reverted: main requires a PR + 1 approval + a passing status check, and the bypass list only covers the repo's Admin role for human users — not the GITHUB_TOKEN used by Actions. The push would have been rejected every time. Folding the updates into the existing release-please PR (version/URL as part of release-please's own commit, date/changelog as a follow-up commit to its PR branch) sidesteps this entirely since that PR already goes through the normal protected merge flow.
Verification
cargo xtask verify (the Verify (Windows) check required on every PR, including release-please's own) now validates website/pad.xml: confirms it's well-formed XML and that Program_Version / Primary_Download_URL match src-egui/Cargo.toml's version. Catches a broken sync (bad regex, malformed XML) before merge instead of after it's live on rigstats.app.
Documented in full in docs/release.md.
Automation (future improvement)
None outstanding — version, download URL, release date, and changelog text are fully automated as of the changes above, and verified pre-merge by cargo xtask verify. If Softpedia (or another directory) needs an exact file size instead of the static PAD default, revisit with a scoped fine-grained PAT stored as a secret, dedicated to just that write.
Goal
Register RIGStats on Softpedia and keep the listing up to date with every new release.
PAD file (recommended submission method)
A PAD (Portable Application Description) file is now maintained at:
Softpedia's submit form (see below) has a dedicated "Use this form if you have a PAD file" section that only needs the PAD URL + contact email — Softpedia parses everything else (version, description, OS support, download URL, file size) straight out of the XML.
Installer filename — important note
The release pipeline produces
RIGStats_{version}_x64-setup.exe(version number baked into the filename). This means direct links to a specific file (/releases/download/v1.35.2/RIGStats_1.35.2_x64-setup.exe) become stale after the next release — see the Automation section below for howwebsite/pad.xmlstays in sync.Download Page URL for Softpedia (always current, used as a fallback field):
One-time submission — DONE
https://rigstats.app/pad.xmlDescription text (embedded in the PAD file, kept here for reference)
Per release — update Softpedia (automated)
website/pad.xmlnow keeps itself in sync automatically across two mechanisms, both landing inside release-please's own release PR (so everything flows through the normal branch-protected merge — no privileged token, no direct push tomain):Program_VersionandPrimary_Download_URLare marked with the samex-release-please-versionmarker comment used insrc-egui/Cargo.toml, andwebsite/pad.xmlis registered inrelease-please-config.json'sextra-files. Release-please bumps both directly whenever it opens/updates the release PR.Program_Release_Month/Day/YearandProgram_Change_Infocan't be set by a simple version-substring bump, sorelease-please.ymlhas an extra step that reads the newest entry release-please just wrote intoCHANGELOG.md(same PR), extracts the date and the bug-fix/feature bullets (stripped of markdown links, joined as "scope: subject; scope: subject"), and pushes a follow-up commit with those PAD fields onto release-please's PR branch (release-please--branches--main). That branch isn't protected the waymainis, so this works with the defaultGITHUB_TOKEN— no bypass needed.End to end: merging the release PR (normal flow, same as any other release) lands the version, download URL, date, and changelog text together on
main.deploy-website.ymlrepublisheswebsite/pad.xmltohttps://rigstats.app/pad.xmlautomatically. Softpedia (and other PAD-aware directories) periodically re-crawl the saved PAD URL and pick up the change on their own — no manual re-submission needed.Not auto-updated (left as-is from the initial submission, cosmetic/low-stakes):
File_Size_Bytes/K/MB. This needs the actual compiled installer, which only exists after the release PR is merged andrelease.ymlbuilds it — by then we're back to the branch-protection problem. Not worth a privileged PAT just for a size figure that only drifts by a few KB per release; revisit only if a directory actually rejects updates over it.Why not push directly from
release.yml?Originally tried updating
website/pad.xmlfrom a post-build step inrelease.yml(after the installer is built, so exact file size is known) and pushing straight tomain. This was reverted:mainrequires a PR + 1 approval + a passing status check, and the bypass list only covers the repo's Admin role for human users — not theGITHUB_TOKENused by Actions. The push would have been rejected every time. Folding the updates into the existing release-please PR (version/URL as part of release-please's own commit, date/changelog as a follow-up commit to its PR branch) sidesteps this entirely since that PR already goes through the normal protected merge flow.Verification
cargo xtask verify(theVerify (Windows)check required on every PR, including release-please's own) now validateswebsite/pad.xml: confirms it's well-formed XML and thatProgram_Version/Primary_Download_URLmatchsrc-egui/Cargo.toml's version. Catches a broken sync (bad regex, malformed XML) before merge instead of after it's live onrigstats.app.Documented in full in
docs/release.md.Automation (future improvement)
None outstanding — version, download URL, release date, and changelog text are fully automated as of the changes above, and verified pre-merge by
cargo xtask verify. If Softpedia (or another directory) needs an exact file size instead of the static PAD default, revisit with a scoped fine-grained PAT stored as a secret, dedicated to just that write.