The bundle embeds the source fingerprint, which covers package.json; the
release:notes script addition moved it, so the three bundle copies must be
rebuilt in the same change.
Issue: #328
User-Visible: no
A stable body aggregates the changelog since the previous STABLE release,
not since the last beta; in-beta-only bugfixes are excluded by the curator
(the draft lists every candidate with its source section); the small-fixes
filler line is legal only when the range carries user-visible work not
itemised in the body — a single-issue hotfix ships without it, and body
bullets must link their issues so the rule stays checkable.
scripts/release-notes.mjs prints the aggregation draft and verifies
docs/RELEASE-NOTES.md (npm run release:notes -- <tag> [--verify]); the
verifier rejects the v1.68.1-style empty filler by execution. STATUS.md
release mechanics updated in the same commit.
Issue: #328
User-Visible: no
Owner decision (chat, 2026-08-27): the running check's name must say what it
does, in Russian. Scripts locate workflows by file name (release-gate.mjs ->
validate.yml), so display names are free; job ids and needs are untouched.
The same content is cherry-picked to main because release workflows execute
from the default branch and process.yml must stay identical in main and dev.
Issue: #327
User-Visible: no
Revert of caf6e6c3. The owner's field report disproved the diagnosis: HACS
2.0.5 downloads zip_release assets fine, because async_download_file strips
the 'tags/' prefix from the composed URL before requesting (hacs/base.py) —
the prefix only survives in the error-log message, which prints the
unnormalized URL. The dacha installed every beta and v1.68.0 through HACS
with zip_release active. The observed 'Failed to download' was a transient
network failure fetching release-assets.githubusercontent.com (five retries
exhausted, one occurrence), not a routing bug.
Issue: #325
User-Visible: no
(cherry picked from commit 5ad0c1cdc3)
Revert of caf6e6c3. The owner's field report disproved the diagnosis: HACS
2.0.5 downloads zip_release assets fine, because async_download_file strips
the 'tags/' prefix from the composed URL before requesting (hacs/base.py) —
the prefix only survives in the error-log message, which prints the
unnormalized URL. The dacha installed every beta and v1.68.0 through HACS
with zip_release active. The observed 'Failed to download' was a transient
network failure fetching release-assets.githubusercontent.com (five retries
exhausted, one occurrence), not a routing bug.
Issue: #325
User-Visible: no
Owner-approved emergency stable hotfix; the release commit changes only version fields, generated bundles and release metadata.
Issue: #324
User-Visible: yes
Owner-approved emergency stable hotfix; the release commit changes only version fields, generated bundles and release metadata.
Issue: #324
User-Visible: yes
Installing a specific version from the HACS catalog fails: HACS composes the
zip_release asset URL from its internal ref 'tags/<version>' without
stripping the prefix (hacs/integration base.py:932 -> download_zip_files ->
github_release_asset), requesting releases/download/tags/v1.68.0/... which
GitHub cannot serve. A mirror tag with a slash is not servable either.
Without zip_release HACS falls back to the regular tag-tree download that
worked before 2026-08-08. Release assets keep being attached
(release-zip.yml untouched) so re-enabling after the upstream fix is a
one-line revert.
Issue: #325
User-Visible: no
(cherry picked from commit caf6e6c355)
Installing a specific version from the HACS catalog fails: HACS composes the
zip_release asset URL from its internal ref 'tags/<version>' without
stripping the prefix (hacs/integration base.py:932 -> download_zip_files ->
github_release_asset), requesting releases/download/tags/v1.68.0/... which
GitHub cannot serve. A mirror tag with a slash is not servable either.
Without zip_release HACS falls back to the regular tag-tree download that
worked before 2026-08-08. Release assets keep being attached
(release-zip.yml untouched) so re-enabling after the upstream fix is a
one-line revert.
Issue: #325
User-Visible: no
CODE-REVIEW-323-r1 M1: the full guides README links to still taught the
custom-repository flow; step 1 now matches the README wording.
Issue: #323
User-Visible: no
The HACS row still described an open queue of 835 PRs; the fresh-install
checklist still started from a custom repository.
Issue: #323
User-Visible: no
Since 2026-08-25 the integration is in the HACS default catalog
(hacs/default#9004); the badge and both install sections no longer route
users through Custom repositories — a plain HACS search finds it.
Issue: #323
User-Visible: no
claude[bot]