net-mqtt-0.5.0.0: Changelog.md

# Changelog for net-mqtt

## 0.5.0.0

Major release for MQTT version 5.

The API is mostly the same, but a list of Property values is passed in
and returned from a few different fields.

Subscribe responses are now more detailed in the error case, and also
return a `[Property]`.

Connections default to `Protocol311` (3.1.1), and all behavior should
be backwards compatible in these cases.  i.e., you can write code as
if it were destined for a v5 broker, but properties won't be sent and
responses will be inferred.  If you specify your `_protocol` as
`Protocol50` in your `MQTTConfig`, the new features should all work.

Various bugs were fixed along the path of making v5 compatibility, but
I'm pretty sure there's one left somewhere.

## 0.2.4.2

Don't set a message ID of 0.

This had been working fine for a while, but starting in mosquitto 1.6,
the server would just hang up on a subscribe request with a message ID
of zero.

## 0.2.4.1

Link QoS2 completion thread on subscriber.

An exception from a subscriber callback could be silently dropped
without completing the handshake which would then cause the MQTT
broker to just stop sending messages to the subscriber.
Unfortunately, the broker (at least mosquitto) still responds to pings
and doesn't give any useful notification that it's no longer sending
messages.

## 0.2.4.0

Introduced `Filter` type alias to distinguish from `Topic`.

Reintroduced timeout management at the protocol layer, dropping a
connection when a pong response hasn't come in in a while (~3x longer
than the current 30s ping rate).  This was mostly after noticing
mosquitto do really weird things where it seemed to just forget about
all my active connections (other clients figured that out and dropped
and reconnected).

## 0.2.3.1

Fixed up github links.

## 0.2.3.0

Added Network.MQTT.Topic with `match` to test `Topic`s against wildcards.

## 0.2.2.0

Added connectURI to make it easier to connect to mqtt or mqtts via
URI.

## 0.2.1.0

No externally visible changes, but a few bug fixes I found when
writing an application that published in QoS < 2.  QoS 0 would likely
not transmit (which is probably fine according to the spec, but not
very desirable) and QoS1 didn't check its ACKs, so it would continue
to retry after the server ACKd the message.

## 0.2.0.0

### API Change

Subscriber callbacks now include the MQTT client as the first
argument.  This breaks a circular dependency that prevented callbacks
from being able to publish messages easily.

### Other

Updated to stackage LTS 13.2