Six merges landed since 0.6.0 was deployed and the version never moved. Disk and box both read 0.6.0, so ha apps update would have been a no-op — Supervisor keys the built image by version:, and the update path installs version_latest, which cannot differ from version without a bump.
Found while pre-checking the deploy, not after it silently did nothing.
⚠️ Minor rather than patch, because the schema changed
SAFETY-32 added bms_soc_floor: int(0,50) as a required per-entry key on the inverters roster — no trailing ? — so a config that declares a roster and omits it on any entry is refused at startup. Verified against the deployed 2d025ee:
An install running inverters: [] is unaffected — which is every single-inverter install including the reference one, where the flat bms_soc_floor still describes the one pack. But CFG-04 recorded the rule: "a schema change without a bump is a schema nobody reads."
Contents since 0.6.0
3934ad7
MAINT-05
67e649a
SPIKE-04a
3993f9f
SAFETY-32
f72c48d
UX-01
86eaef2
TEL-07
4482cd8
SAFETY-41
One thing recorded rather than papered over
0.6.0 was never sectioned. Its content sits below the new 0.7.0 heading because that bump shipped without cutting a section. Splitting it retroactively would mean guessing a boundary; the deployed 0.6.0 is 2d025ee and the table says what is new since it. Saying so is more useful than a guess.
**Six merges landed since 0.6.0 was deployed and the version never moved.** Disk and box both read `0.6.0`, so `ha apps update` would have been a **no-op** — Supervisor keys the built image by `version:`, and the update path installs `version_latest`, which cannot differ from `version` without a bump.
Found while pre-checking the deploy, not after it silently did nothing.
### ⚠️ Minor rather than patch, because the schema changed
SAFETY-32 added `bms_soc_floor: int(0,50)` as a **required** per-entry key on the `inverters` roster — no trailing `?` — so a config that declares a roster and omits it on any entry is **refused at startup**. Verified against the deployed `2d025ee`:
| | 2d025ee (deployed) | now |
|---|---|---|
| per-entry roster keys | 6 | **7** |
| top-level options / schema | 63 / 63 | 63 / 63 |
An install running `inverters: []` is unaffected — which is every single-inverter install including the reference one, where the flat `bms_soc_floor` still describes the one pack. But CFG-04 recorded the rule: *"a schema change without a bump is a schema nobody reads."*
### Contents since 0.6.0
| | |
|---|---|
| `3934ad7` | MAINT-05 |
| `67e649a` | SPIKE-04a |
| `3993f9f` | SAFETY-32 |
| `f72c48d` | UX-01 |
| `86eaef2` | TEL-07 |
| `4482cd8` | SAFETY-41 |
### One thing recorded rather than papered over
**0.6.0 was never sectioned.** Its content sits below the new 0.7.0 heading because that bump shipped without cutting a section. Splitting it retroactively would mean guessing a boundary; the deployed 0.6.0 is `2d025ee` and the table says what is new since it. Saying so is more useful than a guess.
Full suite: **21 passed, 0 failed.**
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
Six merges landed since 0.6.0 was deployed and the version never moved.
Disk and box both read 0.6.0, so `ha apps update` would have been a
NO-OP: Supervisor keys the built image by `version:`, and the update path
installs `version_latest`, which cannot differ from `version` without a
bump. Found while pre-checking the deploy, not after it silently did
nothing.
⚠️ MINOR RATHER THAN PATCH, BECAUSE THE SCHEMA CHANGED. SAFETY-32 added
`bms_soc_floor: int(0,50)` as a REQUIRED per-entry key on the `inverters`
roster - no trailing `?` - so a config declaring a roster and omitting it
on any entry is refused at startup. Verified against the deployed
2d025ee: the per-entry schema went from 6 keys to 7. Top-level options
and schema are unchanged at 63 each.
An install running `inverters: []` is unaffected, which is every
single-inverter install including the reference one: the flat
`bms_soc_floor` still describes the one pack. But CFG-04 recorded the
rule this follows - "a schema change without a bump is a schema nobody
reads" - and this is exactly that shape.
The CHANGELOG gains a 0.7.0 section listing the six merges by SHA. It
also records, rather than papers over, that 0.6.0 was never sectioned:
its content sits below the new heading because the earlier bump shipped
without cutting a section. Splitting it retroactively would mean guessing
a boundary; the deployed 0.6.0 is 2d025ee and the table says what is new
since it.
Full suite: 21 passed, 0 failed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
admin
merged commit bbc903b2b4 into release/1.02026-09-05 19:23:16 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Six merges landed since 0.6.0 was deployed and the version never moved. Disk and box both read
0.6.0, soha apps updatewould have been a no-op — Supervisor keys the built image byversion:, and the update path installsversion_latest, which cannot differ fromversionwithout a bump.Found while pre-checking the deploy, not after it silently did nothing.
⚠️ Minor rather than patch, because the schema changed
SAFETY-32 added
bms_soc_floor: int(0,50)as a required per-entry key on theinvertersroster — no trailing?— so a config that declares a roster and omits it on any entry is refused at startup. Verified against the deployed2d025ee:2d025ee(deployed)An install running
inverters: []is unaffected — which is every single-inverter install including the reference one, where the flatbms_soc_floorstill describes the one pack. But CFG-04 recorded the rule: "a schema change without a bump is a schema nobody reads."Contents since 0.6.0
3934ad767e649a3993f9ff72c48d86eaef24482cd8One thing recorded rather than papered over
0.6.0 was never sectioned. Its content sits below the new 0.7.0 heading because that bump shipped without cutting a section. Splitting it retroactively would mean guessing a boundary; the deployed 0.6.0 is
2d025eeand the table says what is new since it. Saying so is more useful than a guess.Full suite: 21 passed, 0 failed.
🤖 Generated with Claude Code
https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU