Publish on crates.io

[thobson88]

Use GitHub account: trustchain-devs with email trustchain.devs@gmail.com.

(Note: this is a new gmail account, not to be confused with trustchaindevstest@gmail.com used for the demo.)

TODO: decide how to publish the whole workspace, given that it's not supported by default (see here).

There's a crate for workspace publishing which looks promising, but to get the right name for the whole workspace I think we'll need to add name = trustchain to the top-level Cargo.toml.

That means making changes after the v0.1.0 tagged commit, which is annoying.

Alternatively we could just do some merging, update the metadata in Cargo.toml, tag the new release as v0.2.0 and publish that instead.

[thobson88]

Remaining tasks for crates.io:

• Check cargo-release whether to use over cargo-publish
• Fix build on 174 (cargo build is broken by the new [package] section in top-level Cargo.toml)
• Make PR from 174 and merge 174 with workspace toml changes
• Tag release as v0.2.0 and publish draft
• Check process for docs.rs publication (is this automatic?)

[sgreenbury]

See documentation guide.

[thobson88]

TODO:

• Doc comments for all modules
• Doc comments for all functions in the public API (but not enum variants)

[thobson88]

UPDATE: We have a major obstacle because all dependencies must themselves be published on crates.io, which is a problem for us because Trustchain depends on our forks of third party repositories (specifically SSI and RSS).

See here and discussion here.

This would mean publishing our forks of those repos before publishing Trustchain, which seems daft.

To get the API docs online (which was part of the motivation for publishing), I'm going to try to build them into the new mkdocs site on GitHub pages #173.

[sgreenbury]

Additional discussion on crates.io and forks.

[thobson88]

Obstacle overcome! See #179 and PR #180.

Next step is to check doc comments and then publish from the publish branch.