Finalise the CHANGELOG for v1.1.0 #140

Merged

claude-bot merged 1 commit from release/v1.1.0 into main

2026-09-06 00:56:34 +00:00

claude-bot commented

2026-09-06 00:45:29 +00:00

Contributor

Prepares the tag. Same shape as the v1.0.0 finalisation (#109): [Unreleased] stays as an empty header and a dated version heading goes in below it, so release.yml's awk has a ## [1.1.0] section to extract as release notes.

Also fixes a defect in what would have shipped

[Unreleased] had accumulated Changed / Fixed / Added / Fixed — two separate ### Fixed blocks. That's mine: adding the #132 entry, I opened a new ### Fixed instead of using the existing one further down. It would have gone out as public release notes with a duplicated heading and the sections out of order.

Now Added / Changed / Fixed, matching [1.0.0].

Purely a reordering. Verified rather than asserted:

the 535 lines of prose are identical before and after by sha256
the [1.0.0] section is byte-identical to HEAD

The extraction was dry-run before committing

Against this exact file, using the workflow's step verbatim:

Extracting notes for 1.1.0
bytes: 38966
fallback fired: no
version headings leaked: 0
identical to the [1.1.0] section: True   (sha 9438b13115ec0e479dc09e72)

Worth saying why that ran in a Linux container rather than locally: through Git Bash the same awk silently loses a backslash, turning \[ into a character class, which matches nothing and extracts zero bytes. That looks exactly like a broken CHANGELOG rather than a broken shell — and it's how the fallback path got exercised on v0.0.1-rc1, so it's worth not misdiagnosing twice.

What happens on the tag

Once this merges, git tag v1.1.0 && git push --tags should produce:


`iris-wled:1.1.0`	`type=semver,{{version}}`
`iris-wled:1.1`	`type=semver,{{major}}.{{minor}}`
`iris-wled:latest`	moves, since `v1.1.0` has no `-` suffix
Forgejo release	`prerelease: false`, body = the `[1.1.0]` section

I'll verify each by effect after the tag, not by reading the log.

🤖 Generated with Claude Code

Prepares the tag. Same shape as the v1.0.0 finalisation (#109): `[Unreleased]` stays as an empty header and a dated version heading goes in below it, so `release.yml`'s awk has a `## [1.1.0]` section to extract as release notes. ## Also fixes a defect in what would have shipped `[Unreleased]` had accumulated **Changed / Fixed / Added / Fixed** — two separate `### Fixed` blocks. That's mine: adding the #132 entry, I opened a new `### Fixed` instead of using the existing one further down. It would have gone out as public release notes with a duplicated heading and the sections out of order. Now **Added / Changed / Fixed**, matching `[1.0.0]`. **Purely a reordering.** Verified rather than asserted: - the 535 lines of prose are identical before and after by sha256 - the `[1.0.0]` section is byte-identical to `HEAD` ## The extraction was dry-run before committing Against this exact file, using the workflow's step verbatim: ``` Extracting notes for 1.1.0 bytes: 38966 fallback fired: no version headings leaked: 0 identical to the [1.1.0] section: True (sha 9438b13115ec0e479dc09e72) ``` Worth saying why that ran in a Linux container rather than locally: through Git Bash the same awk silently loses a backslash, turning `\[` into a character class, which matches nothing and extracts **zero bytes**. That looks exactly like a broken CHANGELOG rather than a broken shell — and it's how the fallback path got exercised on `v0.0.1-rc1`, so it's worth not misdiagnosing twice. ## What happens on the tag Once this merges, `git tag v1.1.0 && git push --tags` should produce: | | | |---|---| | `iris-wled:1.1.0` | `type=semver,{{version}}` | | `iris-wled:1.1` | `type=semver,{{major}}.{{minor}}` | | `iris-wled:latest` | moves, since `v1.1.0` has no `-` suffix | | Forgejo release | `prerelease: false`, body = the `[1.1.0]` section | I'll verify each by effect after the tag, not by reading the log. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-09-06 00:45:29 +00:00

Finalise the CHANGELOG for v1.1.0

CI / Dockerfile lint (pull_request) Successful in 15s

Details

CI / Alembic migration check (pull_request) Successful in 1m3s

Details

CI / Pre-commit hooks (pull_request) Successful in 1m16s

Details

CI / Python lint & type-check (pull_request) Successful in 1m32s

Details

CI / Frontend lint, test & build (pull_request) Successful in 1m40s

Details

CI / Python tests (pull_request) Successful in 5m2s

Details

CI / Docker build, health smoke & E2E (pull_request) Successful in 5m14s

Details

0289bf07d4

Same shape as the v1.0.0 finalisation: [Unreleased] stays as an empty
header and a dated version heading goes in below it, so the release
workflow's awk has a `## [1.1.0]` section to extract.

Also merges the section headings. Unreleased had accumulated Changed /
Fixed / Added / Fixed -- two separate `### Fixed` blocks, because when I
added the #132 entry I opened a new one instead of using the existing one
further down. That would have shipped as public release notes with a
duplicated heading and the sections out of order. They are now Added /
Changed / Fixed, matching [1.0.0].

Purely a reordering: the 535 lines of prose are identical before and
after by sha256, and the [1.0.0] section is byte-identical to HEAD.

The extraction was dry-run before committing, against this file, using
the workflow's step verbatim in a Linux container -- 38,966 bytes,
byte-identical to the section, fallback not fired, no version headings
leaked. Worth doing in a container: run through Git Bash the same awk
silently loses a backslash, turning `\[` into a character class, matching
nothing and extracting zero bytes. That would have looked exactly like a
broken CHANGELOG rather than a broken shell.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot merged commit 1023e945bd into main

2026-09-06 00:56:34 +00:00

claude-bot deleted branch release/v1.1.0

2026-09-06 00:56:34 +00:00

claude-bot referenced this pull request from a commit

2026-09-06 00:56:34 +00:00

Finalise the CHANGELOG for v1.1.0 (#140)