Bump version to 26.9.0 - #18
Merged
Merged
Conversation
3 tasks
The tap had drifted a release behind Screenly/cli, which shipped v26.9.0 on 2026-09-03 while this formula still pinned v26.8.0. Also expand the README with the sync contract and a drift check, so the next bump does not depend on remembering an undocumented step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
Remove the explicit `version` field rather than rewriting it as "26.9.0".
Homebrew derives the version from the tag and already strips the leading
`v`, so `tag: "v26.9.0"` yields version `26.9.0` on its own. That also
halves the bump surface: `tag:` is now the only line a release touches, so
the version can no longer drift out of step with the tag it builds from.
The `v` was not merely cosmetic. Homebrew tokenises a leading `v` as a
StringToken, which sorts below any NumericToken, so every `v`-prefixed
version compares as older than every bare one:
v26.8.0 -> [StringToken "v", 26, 8, 0]
26.9.0 -> [26, 9, 0]
Verified against Homebrew 7.0.1 that this transition upgrades cleanly
(26.9.0 > v26.8.0), and that `Version.detect` on the git URL + tag returns
exactly "26.9.0". Note the ordering makes this one-way: reverting to a
`v`-prefixed version would read as a downgrade and would not upgrade users
back. Homebrew's own audit forbids the prefix anyway --- see the
FormulaAudit/Version cop in Library/Homebrew/rubocops/version.rb.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>
vpetersson-bot
force-pushed
the
release-26.9.0
branch
from
September 15, 2026 08:06
1862e8e to
294763c
Compare
sergey-borovkov
approved these changes
Sep 22, 2026
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.
Summary
The tap had drifted a full release behind
Screenly/cli: the CLI shipped v26.9.0 on 2026-09-03, whileFormula/screenly-cli.rbstill pinned v26.8.0. Anyone installing viabrew install screenly-clihas been getting the older build since then.This moves
tag:tov26.9.0and removes the explicitversionfield. Verified the tag exists upstream before pinning it:Dropping the
v— by deletion, not by rewritingRather than changing
version "v26.9.0"→version "26.9.0", the field is gone. Homebrew derives the version from the tag and already strips thev, verified against Homebrew 7.0.1:So the formula gets the bare version for free,
tag:becomes the only line a release touches, and the version can no longer drift out of step with the tag it builds from — which is the whole point of this issue.The
vwas not cosmetic. Homebrew tokenises a leadingvas aStringToken, which sorts below anyNumericToken:That means every
v-prefixed version compares as older than every bare one —0.0.1 > v26.9.0is true. Two consequences:26.9.0 > v26.8.0, so existing installs upgrade cleanly rather than silently believing they are current.vprefix would read as a downgrade and would not upgrade users back.Homebrew's own linter forbids the prefix regardless —
FormulaAudit/Versionraises "Version … should not have a leading 'v'", and unlike theGitUrlscops it is not scoped tohomebrew-core, so it applies to this tap.No
sha256to recompute:urlpins a git tag, not a release tarball. (Therevision:companion that homebrew-core wants alongside atag:is core-only and does not apply here.)Also: README
Expanded with the sync contract and a copy-pasteable drift check, plus a note not to reintroduce a
versionline. The root cause of the drift is that this repo has no automation pointing at it and nothing fails loudly when the bump is skipped.The matching upstream change is Screenly/cli#323.
🤖 Generated with Claude Code