Update base-client min version to v0.11

[Marenz]

No description provided.

[Copilot]

Pull Request Overview

This PR updates the minimum version of frequenz-client-base to v0.11, adds test assertions for new streaming event types, and documents the change in the release notes.

• Bumped frequenz-client-base version constraint in pyproject.toml.
• Extended tests/test_client.py to assert StreamStarted and StreamRetrying events.
• Updated RELEASE_NOTES.md to mention new streaming notification types.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tests/test_client.py	Add imports and repeated assertions for new stream event types.
pyproject.toml	Bump frequenz-client-base dependency to >=0.11.0, <0.12.0.
RELEASE_NOTES.md	Document handling of StreamStarted, StreamRetrying, and StreamFatalError.

Comments suppressed due to low confidence (1)

tests/test_client.py:1069

• The tests cover retry logic but don’t include a StreamFatalError scenario. Consider adding a test case that triggers and asserts StreamFatalError to match the release notes.

assert isinstance(await receiver.receive(), StreamStarted)

[llucax]

No, wait! You need to also update all the type hints for the client streaming methods, they are only returning XxxData now, but they should return also StreamingEvents or whatever it was called.

[Marenz]

Updated. CI will fail until we release base-client v0.11

[llucax]

Still missing all the component-specific methods using _new_component_data_receiver(), like meter_data(), inverter_data(), etc.

[Marenz]

It's a bit inconsistent that there is one method stream_ that streams data and a bunch of mixed others that might or might not stream something.

[llucax]

It's a bit inconsistent that there is one method stream_ that streams data and a bunch of mixed others that might or might not stream something.

The xxx_data() methods are old, in the v0.17 branch all will have the same naming pattern (but we'll also have only one method for all component types, so it won't matter so much). The sensor support was added recently so I wanted to use a more "modern" interface, so people that start using it have a simpler upgrade path.

[llucax]

I'm changing this to a draft until we decide what we do with the new events, if we really want to mix them with real data.

[llucax]

I'm thinking that another alternative if we want to move forward more quickly (in case this is blocking something), we could just filter the events here in the client for now, and keep sending only data via the streams. So basically we contain the breaking change in the client-base for now until we find a solution we are happy with.

[llucax]

But this will quickly spread though other clients, so we need to find a sustainable solution for the base-client soon, we shouldn't end up with all clients filtering the events internally (except for dispatch).