Problem
logos-package-manager-module (pinned into basecamp v0.1.1 at rev 2fa7da9558ca1746eda59abad4d6efb83303cdca) constructs its package-catalog URL from a release tag held in m_releaseTag. That field is initialized to "latest" and exposes a setRelease(tag) setter — but nothing in the v0.1.1 chain ever calls setRelease.
Searched across:
logos-basecamp @ a746cdb (v0.1.1): 0 hits for setRelease in app/main.cpp, src/MainUIBackend.cpp, or anywhere else.logos-package-manager-ui @ 337240f: 0 hits in src/PackageManagerBackend.cpp, src/package_manager_ui_plugin.cpp, app/main.cpp, app/mainwindow.cpp.
So in practice, basecamp v0.1.1 always asks logos-modules/releases/latest for its catalog, regardless of when the basecamp release itself was cut.
Why this matters
The catalog served from logos-modules/releases/<tag>/list.json implicitly defines the set of module versions the release is expected to work with. Because v0.1.1 pulls "whatever was latest at query time," any future release on logos-modules/latest that breaks API compatibility with basecamp v0.1.1's capability/package-manager modules will immediately break basecamp v0.1.1 UIs in the wild — there's no per-release pairing.
This also blocks downstream tooling (e.g. logos-scaffold) from doing the reasonable thing of "build matching dev .lgx variants automatically": scaffold can't point at "the logos-modules release that pairs with basecamp v0.1.1" because there isn't one. We end up carrying hand-picked module pins in scaffold rather than deriving them from basecamp's own contract.
Suggested fix
Pin the release tag at basecamp build time. Either:
-
Compile-time define in basecamp's CMake / nix build:
add_compile_definitions(BASECAMP_MODULES_RELEASE_TAG=\"build-20260319-33a647b-72\")
and have logos-basecamp's main.cpp (or the first site that can reach the package-manager plugin) call setRelease(BASECAMP_MODULES_RELEASE_TAG) during startup, before the UI loads.
-
Runtime config file shipped alongside the binary (e.g. share/logos-basecamp/modules-release.json) that basecamp reads at startup and passes to setRelease. Slightly more flexible (can be overridden by package maintainers) but more surface.
Either way, each logos-basecamp release ships a coherent logos-modules companion tag.
Reproduction
- Check out basecamp at
a746cdbc521f72ee22c5a4856fd17a9802bb9d69.
- Grep:
grep -rn setRelease src/ app/ — 0 hits.
- Inspect
src/lib/package_manager_lib.cpp:36 in the pinned logos-package-manager-module — constructor initializer , m_releaseTag(QStringLiteral(\"latest\")).
- At runtime, basecamp UI fetches
https://github.com/logos-co/logos-modules/releases/latest/download/list.json.
Context
This issue surfaced while implementing logos-scaffold's dev-mode companion-module install flow. The scaffold PR: logos-co/scaffold#75. The scaffold PR's follow-up plan assumes basecamp will pin the catalog tag so scaffold can derive matching dev variants automatically; until this lands, scaffold will carry opinionated default pins for the common companion set (delivery_module at 1.0.0, etc.).
Happy to send a PR if the compile-time-define approach sounds right.
Problem
logos-package-manager-module(pinned into basecamp v0.1.1 at rev2fa7da9558ca1746eda59abad4d6efb83303cdca) constructs its package-catalog URL from a release tag held inm_releaseTag. That field is initialized to"latest"and exposes asetRelease(tag)setter — but nothing in the v0.1.1 chain ever callssetRelease.Searched across:
logos-basecamp@a746cdb(v0.1.1): 0 hits forsetReleaseinapp/main.cpp,src/MainUIBackend.cpp, or anywhere else.logos-package-manager-ui@337240f: 0 hits insrc/PackageManagerBackend.cpp,src/package_manager_ui_plugin.cpp,app/main.cpp,app/mainwindow.cpp.So in practice, basecamp v0.1.1 always asks
logos-modules/releases/latestfor its catalog, regardless of when the basecamp release itself was cut.Why this matters
The catalog served from
logos-modules/releases/<tag>/list.jsonimplicitly defines the set of module versions the release is expected to work with. Because v0.1.1 pulls "whatever was latest at query time," any future release onlogos-modules/latestthat breaks API compatibility with basecamp v0.1.1's capability/package-manager modules will immediately break basecamp v0.1.1 UIs in the wild — there's no per-release pairing.This also blocks downstream tooling (e.g.
logos-scaffold) from doing the reasonable thing of "build matching dev.lgxvariants automatically": scaffold can't point at "thelogos-modulesrelease that pairs with basecamp v0.1.1" because there isn't one. We end up carrying hand-picked module pins in scaffold rather than deriving them from basecamp's own contract.Suggested fix
Pin the release tag at basecamp build time. Either:
Compile-time define in basecamp's CMake / nix build:
and have
logos-basecamp'smain.cpp(or the first site that can reach the package-manager plugin) callsetRelease(BASECAMP_MODULES_RELEASE_TAG)during startup, before the UI loads.Runtime config file shipped alongside the binary (e.g.
share/logos-basecamp/modules-release.json) that basecamp reads at startup and passes tosetRelease. Slightly more flexible (can be overridden by package maintainers) but more surface.Either way, each
logos-basecamprelease ships a coherentlogos-modulescompanion tag.Reproduction
a746cdbc521f72ee22c5a4856fd17a9802bb9d69.grep -rn setRelease src/ app/— 0 hits.src/lib/package_manager_lib.cpp:36in the pinnedlogos-package-manager-module— constructor initializer, m_releaseTag(QStringLiteral(\"latest\")).https://github.com/logos-co/logos-modules/releases/latest/download/list.json.Context
This issue surfaced while implementing
logos-scaffold's dev-mode companion-module install flow. The scaffold PR: logos-co/scaffold#75. The scaffold PR's follow-up plan assumes basecamp will pin the catalog tag so scaffold can derive matching dev variants automatically; until this lands, scaffold will carry opinionated default pins for the common companion set (delivery_moduleat1.0.0, etc.).Happy to send a PR if the compile-time-define approach sounds right.