Any idea when MQTTnet 5.0 will officially be released?

[nietras]

Hi, I am looking at having to upgrade a 4 year old MQTTnet project and facing a lot of breaking changes just going from 3.x to 4.x and even from 3.0.x to 3.0.y. In that process it seems prudent to jump straight to MQTTnet 5.0 instead of 4.x since more breaking changes are introduced in that. But is 5.0 ready for production? When will it be officially released and so on?

On a side note, we use the abstractions (interfaces) in MQTTnet 3.x a lot for doing testing, stubbing etc. and it's sad to see these being removed and many types being completely impossible to use or define externally (e.g. types that are now sealed and only have internal set properties or similar). This means we have to introduce a lot of these abstractions ourselves leading to duplicate work, and we wonder why this is done by library authors?

In general we are a bit worried by the many breaking changes we have observed e.g. even from 3.0.11 to 3.0.16 there were some.

Thanks for great library nonetheless :)

[chkr1011]

We are still working on memory improvements. Apart from that there is no feature left for version 5. I expect that the first release will be in a few months.

The abstractions are reduced in version 4 to reduce breaking changes. Version 3 had a lot of abstractions but unfortunately it leads to lots of breaking changes especially when new features are added. Sometimes there were just a few constructors changed or method signatures, but people start complaining because they often have to change their code just to get the benefits of security fixes etc.

Apart from that my personal recommendation is to always create your own abstractions so that you can exchange the library with a another one. This makes it also easier to change from another library to this one. I usually avoid that code (and tests) is heavily depending on any library (apart from .NET Framework).

But I agree that the limitations in the early versions of version 4 are too much. So, we readded some interfaces and public stuff again.
Please let me know what abstractions you are missing (in version 5). Maybe we find a way to fulfill both needs.

[nietras]

Thank you for your reply. I can certainly understand that with interfaces comes contracts and that these can change... there are many ways to solve it though and with recent C# many more ways. In any case, an example of a problem we are facing is that MqttClientConnectResult is impossible to use in testing since it is sealed and only internally setable. Hence, this cannot be created in any real way.

Another issue is the async events that return Task, which are a bit weird in .NET given events can have multiple handlers and hence it has been a long time recommendation to never have return values on those. The issue here is this makes them harder to "mock". There are ways around it, but the design is a bit outside normal. Although, this pattern is seen in other libraries even ones from MS.

[nietras]

Regarding the Result types, it seems that many of these could be immutable records instead, so they are fully creatable e.g. with { get; init; } properties instead given results are allocated no matter what.