Set polkadot version in one place

[gilescope]

Rust 1.64 enables workspace properties ( https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table ).

No need to bump version numbers by script any more ( https://github.com/paritytech/release-engineering/blob/master/scripts/release-lib.sh#L644 ), we can just set it in one place.

I'm sure there are other ways we can make use of the new capabilities in 1.64, but this seems like a sensible first step.

[gilescope]

Hmm CI only has rust 1.62.

[gilescope]

Please wait till Chevor gives the nod before we merge this.

[ordian]

Can we reuse authors, edition and set repository to https://github.com/paritytech/polkadot?

[chevdor]

Let me line up a PR for the release scripts.

I see you did not include:

• orchestra-proc-macro
• orchestra
• prioritized-metered-channel

to the list of crates following the workspace version which is a good thing. cc @drahnr

[chevdor]

There is a fix lined up for the release scripts.

[chevdor]

FYI: I published a new binary for toml-cli to support the new format (toml version 0.2.1 breaks due to the unexpected . in the workspace.package key) : https://github.com/chevdor/toml-cli/releases/tag/v0.2.2

[gilescope]

FYI cargo-spellcheck is getting updated to support this: drahnr/cargo-spellcheck#284

[gilescope]

Going to wait to merge this till after barcamp/sub0 as there's bound to be at least another tool that wasn't expecting this change.

[joao-paulo-parity]

This was brought to my attention by @chevdor (thanks for pinging me on this).

In lieu of https://github.com/paritytech/release-engineering/issues/120 I'm wondering about how this is supposed to interact with individual crate releases. While that ticket is about Substrate and this is about Polkadot, I'm wondering if we'll be interested in releasing Polkadot crates in the future as well.

First an aside on why it's relevant to maintain per-package version. Before releasing a crate we bump its version individually (and that is unrelated to the workspace's version). Logically, in order to perform the bump we need to know what's the crate's highest published version, which is commonly tracked by the source code (see dtolnay/syn@78fa618 for example). It's not necessary, however, to imprint the crate's highest published version in the source code because that can be figured out by querying https://crates.io/api/v1/crates/$CRATE/versions; the upcoming publishing automation makes use of that endpoint, thus it can figure out the highest published version by itself and therefore we wouldn't need to manually track the version through the source code, nor need to maintain per-package version.

By the PR's description I infer that this change is catered to the release processes we have currently, not the "individual crate releases" use-case. We should consider if it obstructs the latter. I think it doesn't because, as explained, the automation can figure out how to bump a crate's version by querying https://crates.io/api/v1/crates/$CRATE/versions even if the crate doesn't have a version field in its Cargo.toml; i.e. the automation would disregard workspace.package.version and set the crate's version field, based on https://crates.io/api/v1/crates/$CRATE/versions, before publishing. Not having per-package version might even be beneficial to the "individual crate releases" use-case because we wouldn't have to submit a PR for updating the Cargo.tomls after crates are published (https://github.com/paritytech/release-engineering/issues/124).

My conclusion is that it's worthwhile to give this a shot because I don't see how it would obstruct the crate releases automation, although the process would become more contrived and unintuitive. Even if we run into some broken/unintended interaction resulting from this change, the automation could remove the new features and normalize the Cargo.tomls before publishing, which would effectively work around the problem.

[gilescope]

bot merge