after the cached messages have been fetched.

when the room features change.

Builds are now themselves UMD modules, so they could be `require`'d like any
other AMD module or they can still be used as old ES5 modules with globals.

Additionally the build is now closured, so that the almond API doesn't pollute
the global context with `define` or `require`. This does however mean that
`require` can no longer be used outside of the build (unless requirej.s is
included directly.

Builds are now themselves UMD modules, so they could be `require`'d like any
other AMD module or they can still be used as old ES5 modules with globals.

Additionally the build is now closured, so that the almond API doesn't pollute
the global context with `define` or `require`. This does however mean that
`require` can no longer be used outside of the build (unless requirej.s is
included directly.

https://greenkeeper.io/

Fixes #620

Also, don't query for MAM messages if the chat room doesn't support it.

allow_non_roster_messaging is false.

Fixes #745

So that when a higher priority resource goes offline, we can fall back to the
right chat status if at the next priority level there are multiple resources.

https://github.com/jcbrand/converse.js/commit/789654d54e7a8c80b35934f526e05ee7802c790f#comments

updates #785

Improve upon the previous implementation.

If the resource with the highest priority goes offline or becomes unavailable,
then the chat status of the contact must fall back to that of the resource with
the next highest priority.

In your example from #785, if the resource with priority 1 goes offline or
becomes unavailable, then in your implementation the chat status would stay at
online, although it must actually go to xa.

The solution is to update the resources attribute on the contact to not just be
an array or strings, but instead to be a map of resources to priorities and
statuses and to use that data structure.