Repository navigation
Conversation
OpenCode 2 tags are published to the same repository without V1 archives. The standard updater takes the highest stable release, so it would pick a 2.x tag for the V1 entry and stop delivering 1.x updates. Keep the entry on releases in its current major version.
danfry1
force-pushed
the
opencode-v1-pin
branch
from
October 24, 2026 21:05
806469e to
b35a8db
Compare
danfry1
changed the title
Open
4 of 6 tasks
hussain
added a commit
to solutionsunity/acp-patchbay
that referenced
this pull request
Nov 6, 2026
An entry that moved back, as asked for `opencode` in agentclientprotocol/registry#716, was offered as an Upgrade: agentUpdates compared the two versions for equality only, so any different version counted. It now weighs them with isNewer, the project's one ordering of versions. The registry's schema fixes `version` to x.y.z, so its numbered parts cover every listed version. The Settings card, the agent's chip and the notice read that one fact, but Upgrade itself didn't: it resolves from a fresh read, so a chip shown before the entry moved back still downgraded on click. The writer now consults the fact after that read and refuses, asking nothing and stopping nothing. What else this changes: - Upgrade when the fresh read equals the pin used to ask, stop and restart; it now refuses too, which leaves previousAfterUpgrade's same-version branch unreachable, so that is gone. - A version that doesn't read as x.y.z, on either side, is never offered. - The refusal is a new native warning. Closes #148
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
opencodeentry is updated from GitHub Releases inanomalyco/opencode, andget_github_release_versionstakes the highest stable release there without checking which one is Latest. OpenCode plans to publish 2.x GitHub Releases in the same repository without V1 archives, while keeping Latest on 1.x (anomalyco/opencode#54903). After that, the updater would pick a 2.x tag for the V1 entry.verify-updatesrejects that update because the archives don't exist, so the entry stays installable, but every run picks a 2.x tag again. The entry then never receives another 1.x release, and each run logs a skipped-update warning. OpenCode 2 already has its ownopencode-v2entry (#657).Add
custom_agent_sources/opencode.pyand register it as the("opencode", "stable")override. It keeps only GitHub Releases in the entry's current major version and returns no resolved assets, so URL rewriting and digest lookup stay on the standard binary path. It returns anUpdateErrorwhen releases can't be fetched, when no release in the current major exists, or when the newest one is older than the entry. The existingtest_v1_keeps_github_release_sourcenow patches the new source, andtests/test_opencode_source.pycovers the 2.x filtering and the error cases.Moving the
opencodeentry to 2.x later is a deliberate change: remove the override, or bump the entry's major version by hand. The release listing is one page of 100, so if more than 100 2.x releases were published after the newest 1.x, the entry would stay where it is rather than move to the wrong release.