Connect with MQTTv5 by default

[RichieB2B]

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?

[PierreF]

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:

• At least if using callback_api_version to version1, the callback change between MQTTv3* and MQTTv5
• I think to clean_session vs clean_start

[RichieB2B]

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?

[PierreF]

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).

[pktiuk]

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?

[pktiuk]

@PierreF