Add Template Release Script

[nuke-web3]

This is a copy&paste addition to be able to produce a stand-alone template (with local->git dependencies) for the included template here. If this seems like a good addition, we can tune this PR to fit the needs better, update the docs here, and mention the way to use it in the devhub, or if we can commit to maintain it, host a template repo just as we have for the https://github.com/substrate-developer-hub/substrate-node-template already.

[sorpaas]

If this seems like a good addition, we can tune this PR to fit the needs better, update the docs here, and mention the way to use it in the devhub, or if we can commit to maintain it, host a template repo just as we have for the https://github.com/substrate-developer-hub/substrate-node-template already.

Yeah definitely! I think this also solves the problem of pinning Substrate master for new users as we received many complaints.

[nuke-web3]

I can confrim that the script works and the unzipped template builds & runs.

Based on the master branch presently (latest commit of this PR) the new Cargo.toml has an not ideal form, but it works:

[dependencies.fc-consensus]
git = 'https://github.com/paritytech/frontier.git'
rev = '2a021f69a2db02106c82c018fac637b647a2b13c'
.......

I will try for the last tag pallet-evm-v4.0.0 as well to see the behavior. Anything else we should test before polishing the instructions for use here?

[nuke-web3]

Ah one thing I think we should use is a fixed tag/release not a floating branch reference in substrate. So the template here would need to be updated and upstream tags set. Right?

[sorpaas]

Ah one thing I think we should use is a fixed tag/release not a floating branch reference in substrate. So the template here would need to be updated and upstream tags set. Right?

We shouldn't use any special tags in cargo.toml. Right now we explicitly set the branch to frontier but even that should be removed shortly, because it turns out cargo interpreta them as different dependencies and will resolve it differently. This makes it incompatible for many projects.

[nuke-web3]

Well typically we see release tags used, like in the node template: https://github.com/substrate-developer-hub/substrate-node-template/blob/master/node/Cargo.toml#L41-L44

This way (assuming the tag is static) there is only one commit upstream that cargo will use, and it's more human friendly to have the tag & version set.

[sorpaas]

This way (assuming the tag is static) there is only one commit upstream that cargo will use, and it's more human friendly to have the tag & version set.

That works if the only git dependencies are directly through the template project. Once you have git dependencies that have git dependencies and both that project and the dependency depends on git substrate, everything will start to break.

[nuke-web3]

Assuming this upstream PR lands, we can also introduce this here paritytech/substrate#9461
with #431 in resolved first. Thus we can copy over the style/formatting from frontier to match in the template.