ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

ci(release): match the existing vX.Y.Z tags, not a component prefix - #808

Merged
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix
Aug 19, 2026
Merged

ci(release): match the existing vX.Y.Z tags, not a component prefix#808
joryirving merged 1 commit into
mainfrom
ci/no-component-tag-prefix

Conversation

@joryirving

Copy link
Copy Markdown
Contributor

Summary

  • Sets include-component-in-tag: false and component: "" on the root package.

Why

release-type: node derives a component from package.jsonname, which is dispatch, and prefixes tags with it. Release-please is therefore looking for dispatch-v0.5.38:

tags that exist v0.5.38, v0.5.37, v0.5.36, ...
tag release-please seeks dispatch-v0.5.38 -> 404

Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.

It is also why #807 looked like it did nothing. bump-patch-for-minor-pre-major worked correctly and demoted the five feat: commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.

Effect

  • Release-please matches v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.
  • The changelog covers this release rather than the whole repo.
  • The v* tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. A dispatch-v* series would orphan all three.

Note

misospace/miso-chat has the same config shape (release-type: node, package name miso-chat) and has already released miso-chat-0.5.0 while its tag series sits at v0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.

@joryirving
joryirving merged commit 078de34 into mainAug 19, 2026
8 checks passed
@joryirving
joryirving deleted the ci/no-component-tag-prefix branch August 19, 2026 16:39

@its-saffronits-saffronBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)

Review Summary

Recommendation: Approve

This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.

Change Analysis

File modified:release-please-config.json

The change adds two properties to the root package configuration under "packages": {".": {}}:

  • "include-component-in-tag": false
  • "component": ""

What this fixes:

The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:

  1. Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
  2. Incorrect version calculations due to ancient breaking changes being within range

What this enables:

  • Matching existing v0.5.38 tags correctly
  • Computing changes over the actual 36 commits since the last release
  • Proposing 0.5.39 instead of incorrect major version bumps
  • Preserving the v* tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on

Required Checks

CheckStatusNotes
CI (all 7 checks)✅ PassBuild, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded
Diff correctness✅ PassAdded properties are valid release-please config options for the "node" release type
JSON validity✅ PassFile read successfully; all CI checks passed (would fail on invalid JSON)
No linked issues✅ PassPR references PR 792 and PR 807 as context but no issue is linked to this PR

Standards Compliance

This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.

Tool Harness Findings

The tool harness verified:

  • The file was read successfully and contains valid JSON
  • Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
  • The commit is signed and verified

Unknowns / Needs Verification

  • References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
  • Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.

Conclusion

This is a correct, minimal fix that:

  1. Directly addresses the root cause of incorrect tag matching
  2. Uses documented release-please configuration options
  3. Has passed all CI checks
  4. Is well-documented in the PR description
  5. Does not affect any application code, database, or runtime behavior

Approve.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@joryirving