deps: floor ebus-mqtt-client at 0.5.0 - #85
Merged
Merged
Conversation
0.5.0 holds retained QoS 0 publishes issued before the link is up and flushes them on connect, and stops warning about each one. That window is one the SDK creates by design rather than an edge case: a root built with mqtt_cfg= connects asynchronously, so a construction-time state_transition can publish before CONNACK. building-a-proxy.md already documents the consequence and tells a producer to wait for is_connected(), but the default path provokes it. At the SDK's default QoS 2 paho already queued those publishes, so what changes there is the warning burst: 3 per boot to 0, measured on a Gen3 lab panel. At QoS 0 it is the difference between those retained publishes arriving and being dropped. Honest about what this floor is: nothing in the SDK imports or requires anything new, and the full suite passes against 0.4.0. It is the same kind of floor as 0.4.0's, which the comment already describes as "the SDK does not import it, but a consumer following that guidance needs it present". It also aligns with meta-span's python3-ebus-sdk recipe, which already floors at 0.5.0 on the device side, so a dev install and a panel now behave the same. No release cut for this; it rides with the next one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Aligns the SDK's declared floor with what the device side already installs.
ebus-mqtt-client 0.5.0 holds retained QoS 0 publishes issued before the link is up and flushes them on connect, and stops warning about each one.
That window is one the SDK creates by design, not an edge case: a root built with
mqtt_cfg=connects asynchronously, so a construction-timestate_transition()can publish before CONNACK.doc/building-a-proxy.mdalready documents the consequence and tells a producer to wait foris_connected(), but the default path provokes it.Being honest about what this floor is
Nothing in the SDK imports or requires anything new, and the full 706-test suite passes against 0.4.0, which is what is installed in my dev environment. So this is not a "the SDK breaks without it" floor.
It is the same kind of floor as 0.4.0's, whose comment already says "the SDK does not import it, but a consumer following that guidance needs it present". If you would rather floors mean strictly "required to function", this one should be dropped and the divergence documented instead — it is a marginal call and I would not argue hard for it.
It also aligns with meta-span's
python3-ebus-sdk_0.23.1.bb, which already floors at 0.5.0 on the device side, so a dev install and a panel behave the same rather than differing in a way nobody would think to check.No release
This rides with whatever the next release is. Bumping a floor is not worth a Yocto rebuild on its own, and the recipe already has 0.5.0.
🤖 Generated with Claude Code