Mid 2026 release plans

[sveinse]

We have two pending releases v0.8.8 and v0.9.0. I've created two milestones which we should use to decide which issue and PR goes into what.

v0.8.8

Milestone: https://github.com/custom-components/zaptec/milestone/9

• Release the the commited fixed in master (see the milestone for list)
• Include any fixes to "immediate" pending issue. Perhaps include HA Companion app goes on black after a few hours when the Zaptec charging station is enabled. #386 if there is a fix coming from that?
• Fixup the last ruff changes in api.py so we do ruff check cleanly before diving into 0.9.0? Wishful thinking perhaps?

v0.9.0

Milestone: https://github.com/custom-components/zaptec/milestone/10

• Breaking changes should go here
• Removal of state attributes, Minimize the number of extra_state_attributes #297
• Refactor the state attributes to use the native Zaptec namespace. E.g. "DeviceType" and not do "device_type" rewrite.

I think we should wait with merging the PRs for v0.9.0 until we've released v0.8.8. Unless we want to start a development branch (but this have caveats, so I hope we can avoid this given that this community is not that active).

Let's use the milestone labels to actively select which fix goes where. Any discussions about the general high-level aspects of these releases should go here.

@steinmn and @rhammen you've been active lately. Any comments or things we should add or remove?

[rhammen]

Both my open PRs are aimed at v0.8.8, non-breaking:

• Fix ruff lint errors in api.py #390 covers the "fixup the last ruff changes in api.py" line item — it takes api.py to 0 ruff errors (ruff check clean), plus two small latent type fixes. One behavior note called out in the PR: the TRY301 fix moves the "stream already running" guard out of the try, so that error now propagates instead of being swallowed — happy to # noqa it instead if you'd rather keep the old behavior.
• Add offline unit tests for the Zaptec API client #391 adds an offline unit-test suite for api.py (fake aiohttp session, no live login), lifting statement coverage ~13% → ~66%. Tests-only, so it's safe for a patch release, and it gives us a safety net before the 0.9.0 attribute work.

One thing to keep in mind for 0.9.0: #391's tests encode the current device_type-style snake_case attributes, so the "native Zaptec namespace" rewrite will need to update some of them — which is exactly what they're there to catch.

I'd suggest tagging both for the v0.8.8 milestone (I don't have access to set it myself).

[rhammen]

Given issue #400, We should also try to include #397.
#397 builds on top of:

• Add offline unit tests for the Zaptec API client #391 : ONLY tests added, so NO changes to functional code
• Retry transient server errors on setup (fixes #392) #393 : fixes Setting up Zaptec integration fails #392
• test: add unit tests for ZaptecUpdateCoordinator and ZaptecBaseEntity #394 : ONLY tests added, so NO changes to functional code
• test: add entity test coverage for sensor/switch/number/button/binary_sensor/update platforms #395 : ONLY tests added, so NO changes to functional code, EXCEPT for a 1 line fix in services.yaml
  My suggestion would be to include all these in 0.8.8

#398: ONLY changes test setup, so NO changes to functional code
My suggestion would be to include this one also in 0.8.8

[rhammen]

Then there is #396 . This adds a Energy sensor for use in the Energy dashboard, that should be correct regarding actual time the charger used electricity.
For me, after a couple of debug iterations, this actually gives me the correct results.
For this one, I would like to get confirmation that it works correctly from more users.
I would say it is thus a "beta" feature.
Also scope is mainly (or only, once the previous PRs are merged ?) on the new statistics,py file, so regression risk for the basic functionality is low.
For this reason my suggestion is to include this one also in 0.8.8, but it is your call.

[sveinse]

I've done some refinement of our open issues and placed issues into a backlog milestone. This was to separate the open user questions from work todo. Use it for issues we'd like to fix, but have no specific plan to fix. Anyone can pick up an issue from this milestone and fix them if they want.

PS! I'm the only one (active) that is able to assign milestones, so please do not hesitate to tag me if you want to have a PR or issue assigned to a specific release.

[sveinse]

Where to set the bar for the 0.8.8 release

Right now we have a lot of active PRs (which is great). Some of them are stacked/chained PRs and are rather large with lots of AI assisted code. Are we getting so many that we should postpone them to 0.9.0? Where do we set the cut-off for 0.8.8? I'd prefer to keep this version small and uncomplicated. I believe we have users are waiting for pending improvements, such as #380.

These rather big and complicated PRs take time to review and they do pose a risk of something unexpected to happen. So my gut feeling is that we are heading into more unstable waters.

[rhammen]

Where to set the bar for the 0.8.8 release

Right now we have a lot of active PRs (which is great). Some of them are stacked/chained PRs and are rather large with lots of AI assisted code. Are we getting so many that we should postpone them to 0.9.0? Where do we set the cut-off for 0.8.8? I'd prefer to keep this version small and uncomplicated. I believe we have users are waiting for pending improvements, such as #380.

These rather big and complicated PRs take time to review and they do pose a risk of something unexpected to happen. So my gut feeling is that we are heading into more unstable waters.

• I have a new branch with the contents of Relax over-strict validation models to fields api.py actually uses (fixes #359) #397 available, based on current master. Need to do a last review, then I create a new PR that replaces 397. This one addressed several open issues; I suggest to include it.
• I also have a new branch wjth the contents of Add per-charger energy statistics feed to fix Energy Dashboard hour-misattribution (fixes #300) #396 (energy sensor) available, based on current master. Without test: migrate coordinator/entity tests to pytest-homeassistant-custom-component harness #414 merged first, test coverage is at around ~60%. Once 414 is merged, I have the additional tests to bring coverage to 100% already available.
• Having 414 in allows building other tests, for other changes/PRs, on top of that framework, so I'd prefer that one in. It is probably the biggest PR of them all.
• No replacement for test: add entity test coverage for sensor/switch/number/button/binary_sensor/update platforms #395 on very short term. Let's postpone that one to 0.9.0, not urgent.
• I still need to check how to make Remove stale devices for deselected chargers after reconfigure (fixes #272) #399, Block Owner/Service-only writes and warn on insufficient role (fixes #311) #401, Refactor services.py: register once in async_setup, fix multi-account resolution #402 compatible with master (or with master + 414). Will do that in the next couple of days. Based on how big/complex the new PRs are you can judge which ones to include and which ones to postpone.

[steinmn]

There is also the migration to https://github.com/ha-zaptec-community (#411) and splitting the API and HA integration into separate repos to consider. The more we add to 0.8.8 here, the more we need to rework into the new repos.

Given that #414 seems to need to split the testing of API and HA anyway, and since it does not provide any direct user-facing benefits, I think it makes sense to do this after the migration.

(the updated version of) #397 seems simple and valuable enough to include in 0.8.8. The translations in #404 and #405 are also simple enough that merging them should be unproblematic. Other than that, I think maybe postponing the rest until after the migration would be my preference.

We should probably also update the readme with some info on the upcoming move to a different repo (for instance to have new issues created in the new repo insttead of the old).