oap/webos-homebrew-channel-builder
Watch
1
0
Fork
You've already forked webos-homebrew-channel-builder
 0
Code Issues Pull requests 1 Projects Releases 10 Packages Wiki Activity Actions

feat: publish rebuilds of an upstream tag as v0.7.3.N #4

Merged
oap merged 1 commit from fix/rebuild-versions into mainline 2026-10-25 03:18:19 -07:00
Conversation 0 Commits 1 Files changed 2 +91 -23
oap commented 2026-10-25 03:17:18 -07:00
Owner
Copy link

Closes #3.

What

  • v0.7.3.N (N = 1..999) is a rebuild of upstream v0.7.3 with the current patches/. It is published as its own release v0.7.3.N, so a patch change can reach an already released version. v0.7.3 works as before.
  • Before the build, appinfo.json is set to app version 0.7.3NNN (v0.7.3.1 -> 0.7.3001). The ipk name, its control file, the service bundle and the manifest all carry it.
  • The index's "don't go backwards" check compares release tags (read from manifestUrl) instead of app versions, because 0.7.3001 sorts above 0.7.4.
  • Refused: a rebuild of x.y.0 (it would clash with upstream x.y.N), and a rebuild number of .0, over 999, or with a leading zero.
  • Also fixed: the job never checked out this repo, so patches/ was missing and "Apply local patches" (#2) would have failed on the next run. It now fetches $GITHUB_SHA first, and that commit is recorded in the release notes.

Why not 0.7.3.1 inside the ipk

The issue's open question, answered from upstream v0.7.3's source:

  • DetailsPanel.js gets the installed version from the TV (getAppInfo, i.e. the installed appinfo.json) and shows "Update" whenever it !== the index's version. versionHigher() is never called.
  • ares-package rejects anything but x.y.z (regex in lib/package.js, in both the locked 3.0.2 and 3.2.6).

So changing only the manifest would leave "Update" lit forever after installing. A 4-part version can't go into the ipk, so the rebuild number goes into the patch field.

Testing

  • Tested the version mapping locally (v0.7.3, v0.7.3.1, v0.7.3.42, v0.7.12.999, v0.8.0, plus the refused cases), the manifestUrl tag parsing against the live index, and the sort -V ordering.
  • Tested the fetch of a commit by SHA from git.owenap.com.
  • The workflow has not been run in CI yet. The first real test is dispatching v0.7.3.1, then checking on the TV that it installs and shows 0.7.3001.

🤖 Generated with Claude Code

Closes #3. ## What - `v0.7.3.N` (N = 1..999) is a rebuild of upstream `v0.7.3` with the current `patches/`. It is published as its own release `v0.7.3.N`, so a patch change can reach an already released version. `v0.7.3` works as before. - Before the build, `appinfo.json` is set to app version `0.7.3NNN` (`v0.7.3.1` -> `0.7.3001`). The ipk name, its `control` file, the service bundle and the manifest all carry it. - The index's "don't go backwards" check compares release tags (read from `manifestUrl`) instead of app versions, because `0.7.3001` sorts above `0.7.4`. - Refused: a rebuild of `x.y.0` (it would clash with upstream `x.y.N`), and a rebuild number of `.0`, over 999, or with a leading zero. - **Also fixed:** the job never checked out this repo, so `patches/` was missing and "Apply local patches" (#2) would have failed on the next run. It now fetches `$GITHUB_SHA` first, and that commit is recorded in the release notes. ## Why not `0.7.3.1` inside the ipk The issue's open question, answered from upstream v0.7.3's source: - `DetailsPanel.js` gets the installed version from the TV (`getAppInfo`, i.e. the installed `appinfo.json`) and shows "Update" whenever it `!==` the index's version. `versionHigher()` is never called. - `ares-package` rejects anything but `x.y.z` (regex in `lib/package.js`, in both the locked 3.0.2 and 3.2.6). So changing only the manifest would leave "Update" lit forever after installing. A 4-part version can't go into the ipk, so the rebuild number goes into the patch field. ## Testing - Tested the version mapping locally (`v0.7.3`, `v0.7.3.1`, `v0.7.3.42`, `v0.7.12.999`, `v0.8.0`, plus the refused cases), the `manifestUrl` tag parsing against the live index, and the `sort -V` ordering. - Tested the fetch of a commit by SHA from git.owenap.com. - The workflow has not been run in CI yet. The first real test is dispatching `v0.7.3.1`, then checking on the TV that it installs and shows `0.7.3001`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
The release tag and the upstream tag were the same value, so a change in
patches/ could not reach an already released version. A 4th component now
marks a rebuild: v0.7.3.1 builds upstream v0.7.3 and publishes as v0.7.3.1.

The app on the TV offers an update whenever the index's version differs
from the installed app's appinfo.json, and ares-package only accepts x.y.z.
So appinfo.json is set before the build to 0.7.3NNN (0.7.3001), which the
ipk, its control file and the manifest then all carry. Rebuilds of x.y.0
are refused, since x.y.N would clash with upstream. The index's
"newer" check now compares release tags, since 0.7.3001 sorts above 0.7.4.

Also check out this repo in the job. The runner does not do it by
itself, so patches/ was missing and "Apply local patches" would have
failed on the next run.

Closes #3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
oap merged commit 4b5e81f3f7 into mainline 2026-10-25 03:18:19 -07:00
oap deleted branch fix/rebuild-versions 2026-10-25 03:18:19 -07:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
oap/webos-homebrew-channel-builder!4
No description provided.