Bump matrix-sdk from 0.5.0 to 0.6.0

[dependabot]

Bumps matrix-sdk from 0.5.0 to 0.6.0.

Release notes

Sourced from matrix-sdk's releases.

2022-09-28 - Matrix SDK 0.6.0

We are proud to announce the release of the next major milestone of matrix development in rust: matrix-sdk 0.6.0 (and matrix-sdk-base, matrix-sdk-crypto, matrix-sdk-common, matrix-sdk-test @0.6.0, [email protected], [email protected] , [email protected], [email protected] and [email protected] respectively), available on crates.io for your convenience.

There are a few major API changes since the 0.5.0 release, listed below. You can find the full list and another troubleshooting section helping you fix common errors you will see when upgrading from 0.5.x to this release in the UPGRADING-0.5-to-0.6.md in the root of the tarball.

Upgrades 0.5 ➜ 0.6

This is a rough migration guide to help you upgrade your code using matrix-sdk 0.5 to the newly released matrix-sdk 0.6 . While it won't cover all edge cases and problems, we are trying to get the most common issues covered. If you experience any other difficulties in upgrade or need support with using the matrix-sdk in general, please approach us in our [matrix-sdk channel on matrix.org][matrix-channel].

Minimum Supported Rust Version Update: 1.60

We have updated the minimal rust version you need in order to build matrix-sdk, as we require some new dependency resolving features from it:

These crates are built with the Rust language version 2021 and require a minimum compiler version of 1.60

Dependencies

Many dependencies have been upgraded. Most notably, we are using ruma at version 0.7.0 now. It has seen some renamings and restructurings since our last release, so you might find that some Types have new names now.

Repo Structure Updates

If you are looking at the repository itself, you will find we've rearranged the code quite a bit: we have split out any bindings-specific and testing related crates (and other things) into respective folders, and we've moved all examples into its own top-level-folder with each example as their own crate (rendering them easier to find and copy as starting points), all in all slimming down the crates folder to the core aspects.

Architecture Changes / API overall

Builder Pattern

We are moving to the [builder pattern][] (familiar from e.g. std::io:process:Command) as the main configurable path for many aspects of the API, including to construct Matrix-Requests and workflows. This has been and is an on-going effort, and this release sees a lot of APIs transitioning to this pattern, you should already be familiar with from the matrix_sdk::Client::builder() in 0.5. This pattern been extended onto:

• the [login configuration][login builder] and [login with sso][ssologin builder],
• [SledStore configuratiion][sled-store builder]
• [Indexeddb configuration][indexeddb builder]

Most have fallback (though maybe with deprecation warning) support for an existing code path, but these are likely to be removed in upcoming releases.

Splitting of concerns: Media

In an effort to declutter the Client API dedicated types have been created dealing with specific concerns in one place. In 0.5 we introduced client.account(), and client.encryption(), we are doing the same with client.media() to manage media and attachments in one place with the [media::Media type][media typ] now.

The signatures of media uploads, have also changed slightly: rather than expecting a reader R: Read + Seek, it now is a simple &[u8]. Which also means no more unnecessary seek(0) to reset the cursor, as we are just taking an immutable reference now.

Event Handling & sync updaes

If you are using the client.register_event_handler function to receive updates on incoming sync events, you'll find yourself with a deprecation warning now. That is because we've refactored and redesigned the event handler logic to allowing removing of event handlers on the fly, too. For that the new add_event_handler() (and add_room_event_handler) will hand you an EventHandlerHandle (pardon the pun), which you can pass to remove_event_handler, or by using the convenient client.event_handler_drop_guard to create a DropGuard that will remove the handler when the guard is dropped. While the code still works, we recommend you switch to the new one, as we will be removing the register_event_handler and register_event_handler_context in a coming release.

Secondly, you will find a new [sync_with_result_callback sync function][sync with result]. Other than the previous sync functions, this will pass the entire Result to your callback, allowing you to handle errors or even raise some yourself to stop the loop. Further more, it will propagate any unhandled errors (it still handles retries as before) to the outer caller, allowing the higher level to decide how to handle that (e.g. in case of a network failure). This result-returning-behavior also punshes through the existing sync and sync_with_callback-API, allowing you to handle them on a higher level now (rather than the futures just resolving). If you find that warning, just adding a ? to the .await of the call is probably the quickest way to move forward.

Refresh Tokens

... (truncated)

Commits

• fefd2a6 chore: crates.io only accepts versioned git deps
• 269bf3a chore: remove old release notes
• 91d1ee9 chore: fix typos in Upgrade guide
• b22fe63 chore: More minor changes of note
• 92467af docs: Upgrading typo fixes
• f1f1c1b chore: Version bump
• ff82d64 chore: specify which crates to release and which not
• b9409b7 docs: more migrations guide
• ea51935 docs: Clarifications in the Upgrade guide
• 2fff5d9 docs: More Upgrade guidance
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #176.