Open RichieB2B opened 4 months ago
That would have been a very good idea for 2.0 due to possible breaking change :/
I'm not sure we could do this without another breaking change and therefor wait for version 3.0. Broker with no support of MQTTv5 don't look a big issue, we could fallback to MQTTv3.11 (as we do for MQTTv3.11 with fallback to MQTTv3). But there is API change between MQTTv5 & MQTTv3.11:
The breaking change in 2.0 and the mention of MQTTv5 on the migration page is the only reason I started looking into this. I never realized that the MQTTv5 standard was released in 2019 and that my MQTT broker already supports it. Pretty odd the client needs a special configuration to use it.
How about attempting to connect with MQTTv5 (with a fallback to MQTTv311) when CallbackAPIVersion.VERSION2
is used?
How about attempting to connect with MQTTv5 (with a fallback to MQTTv311) when CallbackAPIVersion.VERSION2 is used?
This indeed seems a good idea. It still needed to check what to do with option that are slightly different between v3 and v5 (e.g. clean_session vs clean_start), but we might probably be able to connect in MQTTv5 by default at least in some cases like the default (the one the most represented in documentation & example).
That would have been a very good idea for 2.0 due to possible breaking change :/
There is already 2.0. What is the status of this issue?
@PierreF
Even with v2.0.0 now released, the default protocol is still MQTTv311:
https://github.com/eclipse/paho.mqtt.python/blob/ebffdc2ca0a43fd87dfd270bbb16007591139626/src/paho/mqtt/client.py#L735
Isn't it time to use MQTTv5 by default?