PKG-06: bump 0.6.0 -> 0.7.0, because the schema changed and nobody bumped

Conversation 0 Commits 1 Files Changed 2

+30 -1

1 Commits

Author SHA1 Message Date

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5	d8e02ad3f8	PKG-06: bump 0.6.0 -> 0.7.0, because the schema changed and nobody bumped checks / unit (pull_request) Successful in 5m2s Details 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	2026-09-05 18:38:41 +02:00

glenn schrooyenandClaude Opus 5

d8e02ad3f8

PKG-06: bump 0.6.0 -> 0.7.0, because the schema changed and nobody bumped

checks / unit (pull_request) Successful in 5m2s

Details

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

2026-09-05 18:38:41 +02:00

PKG-06: bump 0.6.0 -> 0.7.0, because the schema changed and nobody bumped #55