Repository navigation
Offer an update only for the release GitHub calls latest - #667
Merged
Merged
Conversation
GitHub's publish dialog has three states, not two: set as the latest release, set as a pre-release, or neither. The updater could only tell two of them apart, and treated the third as latest. It read the list endpoint and took the first release that was neither a draft nor a pre-release. A release published with nothing ticked comes back as `draft: false, prerelease: false`, indistinguishable from a promoted one by any field the list carries, so it was offered to every install. That is not a fault anyone hits by following the release runbook, which publishes as a pre-release and promotes afterwards. It is a fault that turns one slip in the publish dialog into a build shipped to everybody, and the runbook itself describes promotion as the thing the updater watches, which was never true: what it watched was the absence of the pre-release flag. So it asks /releases/latest, which answers the question directly. That endpoint returns the release marked latest and nothing else, excludes drafts and pre-releases by definition, and 404s while every release is a pre-release, which is the correct answer to "is there an update" in exactly the window between publishing and promoting. The draft and pre-release checks stay as belt and braces rather than as the decision, so a change in that endpoint's behaviour leaves the app quiet instead of inheriting it. Six tests, where there were none. Two of them fail without this change, including the one that needs both endpoints stubbed to express the bug at all: the unpromoted release is absent from /releases/latest and present in the list.
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.
Closes #666
GitHub's publish dialog has three states, not two: set as the latest release, set as a pre-release, or neither. The updater could only tell two of them apart, and treated the third as latest.
What was wrong
checkForUpdateread the list endpoint and took the first release that was neither a draft nor a pre-release:A release published with nothing ticked comes back as
draft: false, prerelease: false, indistinguishable from a promoted one by any field the list carries, so it was pushed to every install.This is not a fault anyone hits by following the release runbook, which publishes as a pre-release and promotes afterwards. It is a fault that turns one slip in the publish dialog into a build shipped to everybody. It is also worth noting that the runbook describes promotion as the moment the updater sees a release, which was never true: what it watched was the absence of the pre-release flag.
What changed
It asks
/releases/latest, which answers the question directly. That endpoint returns the release marked latest and nothing else, excludes drafts and pre-releases by definition, and 404s while every release is a pre-release, which is the correct answer to "is there an update" in exactly the window between publishing and promoting.The
draftandprereleasechecks stay, as belt and braces rather than as the decision, so a change in that endpoint's behaviour leaves the app quiet rather than inheriting it.This reverses a deliberate choice recorded in the old comment, that the decision belonged in code rather than in GitHub's endpoint semantics. That reasoning is what changes: "whatever GitHub calls latest" is the rule we actually want.
Tests
Six, where there were none. Two fail without this change, including the one that needs both endpoints stubbed to express the bug at all: the unpromoted release is absent from
/releases/latestand present in the list.The rest pin the cases that must stay silent: a pre-release, a draft, a 404 while nothing is promoted, and the running version matching the latest one.
stubUpdateCheckinhelpers.mjsnow stubs a single object rather than an array, and its comment no longer says the app polls the list.Verified
Playwright 195 passing,
node --checkover every module, i18n coverage clean.