Version: pldmgr v0.5.1 | Custom repository `version` field ignored for update detection when filename contains no version string #95

New issue

Open

opened 2026-09-12 14:31:54 -05:00 by RDX-Sci01 · 1 comment

RDX-Sci01 commented

2026-09-12 14:31:54 -05:00

(Migrated from github.com)

Description | Version: pldmgr v0.5.1

The version field in custom repository JSON is documented as being used for update checks, but the manager currently determines the installed version by parsing it back out of the saved filename — not from stored metadata. This means update detection silently fails for any payload whose filename doesn't include the version string.

Steps to reproduce

Add the rdx-sci01 custom repository: https://rdx-sci01.github.io/PLDMGR_JSON/payloads.json
Download a payload with a plain filename and a set version field — e.g. kstuff (filename: "kstuff.elf", version: "v1.10") or bfpilot (filename: "bfpilot.elf", version: "v0.4.4")
When the repository updates that payload to a newer version, no update badge or prompt appears

Expected behaviour

The version field in the repository JSON is used to compare against the installed version, triggering an update notification when it changes — regardless of the filename format.

Actual behaviour

No update is detected. The manager tries to extract a version from the local filename (e.g. kstuff.elf), finds none, and cannot compare — effectively ignoring the version field entirely.

Why this matters

CUSTOM_REPOSITORIES.md explicitly documents version as:

"Version string used for update checks (e.g. "v1.0")"

There is a clear documented contract being broken. Many real-world community repositories use plain filenames (no version in the name), so this affects a broad set of third-party sources.

Root cause

At download time, the manager saves the file but does not persist the version value from the JSON alongside it. Later, when checking for updates, it re-parses the filename to infer the installed version — which fails for plain filenames like kstuff.elf or bfpilot.elf.

Note: v0.3.3 fixed the display of the version label (showing it from the JSON field instead of guessing from the filename) — but the update comparison is still broken because the installed-side version still comes from filename parsing.

Suggested fix

At download time, store the version value from the JSON in local payload metadata (alongside the filename, source URL, etc.). Use this stored value — not a re-parsed filename — when comparing against the repository's current version on update checks.

Workaround for repository maintainers (short-term)

Embed the version in the filename field so the manager can parse it:

{
  "name": "kstuff",
  "filename": "kstuff-v1.10.elf",
  "url": "https://github.com/.../kstuff.elf",
  "version": "v1.10"
}

The url still points to the actual file; the local copy is saved with a versioned name the manager can parse. This is a workaround — the proper fix belongs in the manager.

## Description | Version: pldmgr v0.5.1 The `version` field in custom repository JSON is documented as being used for update checks, but the manager currently determines the *installed* version by parsing it back out of the saved filename — not from stored metadata. This means update detection silently fails for any payload whose filename doesn't include the version string. ## Steps to reproduce 1. Add the `rdx-sci01` custom repository: `https://rdx-sci01.github.io/PLDMGR_JSON/payloads.json` 2. Download a payload with a plain filename and a set `version` field — e.g. `kstuff` (`filename: "kstuff.elf"`, `version: "v1.10"`) or `bfpilot` (`filename: "bfpilot.elf"`, `version: "v0.4.4"`) 3. When the repository updates that payload to a newer version, no update badge or prompt appears ## Expected behaviour The `version` field in the repository JSON is used to compare against the installed version, triggering an update notification when it changes — regardless of the filename format. ## Actual behaviour No update is detected. The manager tries to extract a version from the local filename (e.g. `kstuff.elf`), finds none, and cannot compare — effectively ignoring the `version` field entirely. ## Why this matters `CUSTOM_REPOSITORIES.md` explicitly documents `version` as: > "Version string used for update checks (e.g. `"v1.0"`)" There is a clear documented contract being broken. Many real-world community repositories use plain filenames (no version in the name), so this affects a broad set of third-party sources. ## Root cause At download time, the manager saves the file but does not persist the `version` value from the JSON alongside it. Later, when checking for updates, it re-parses the filename to infer the installed version — which fails for plain filenames like `kstuff.elf` or `bfpilot.elf`. Note: v0.3.3 fixed the *display* of the version label (showing it from the JSON field instead of guessing from the filename) — but the *update comparison* is still broken because the installed-side version still comes from filename parsing. ## Suggested fix At download time, store the `version` value from the JSON in local payload metadata (alongside the filename, source URL, etc.). Use this stored value — not a re-parsed filename — when comparing against the repository's current `version` on update checks. ## Workaround for repository maintainers (short-term) Embed the version in the `filename` field so the manager can parse it: ```json { "name": "kstuff", "filename": "kstuff-v1.10.elf", "url": "https://github.com/.../kstuff.elf", "version": "v1.10" } ``` The `url` still points to the actual file; the local copy is saved with a versioned name the manager can parse. This is a workaround — the proper fix belongs in the manager.

khan-Fayyaz commented

2026-09-16 12:45:43 -05:00

(Migrated from github.com)

i found this issue also when i added my custom source repository. in payload-manager, i wasn't getting any update shown next to payloads which has updated version available on github