Tracking issue for continuous crate deployment

[Xanewok]

This issue tracks the progress and blocking issues related to continous crate deployment. It will be periodically updated should any progress be made or new blocking items found.

Context

At the time of writing, a version 2.0 of Substrate and related crates has finally been released. This monorepo now easily covers almost a hundred of public crates and so the release process itself is somewhat involved, so we want to make it less tedious and automate the crate release process.

To help with that, a tool called cargo-unleash has been created (which already helped release 2.0) and we'd like to further extend its functionality to completely cover our auto-release procedure.

Work items

• [ ] Release cargo-unleash with semverver integration
• [ ] Fix internal (compiler) errors in semverver for every Substrate-related package
• [ ] Fix false positives due to not sharing public dependencies in semverver (not strictly blocking)
• [ ] Ensure latest Substrate packages in crates.io build for the newest nightly toolchain (otherwise we can't compare public APIs with semverver)
• [ ] Setup a CI job that runs semver check on every PR

cc @gnunicorn

[xlc]

I guess we won't see FRAME moved out from Substrate?

[gnunicorn]

I guess we won't see FRAME moved out from Substrate?

This is completely unrelated. Whether the code lives in one or two repositories, isn't relevant for this issue.

[xlc]

My point is move FRAME out of Substrate will also require major change on release flow, e.g. substrate-node may need to move out to avoid circular dependencies. I see a lot of investment on improving the release flow for mono repo and I feel it will increase the friction to transition into multi repo flow.

But this is just an outsider’s point of view so please enlighten me if you have more info.