Bump parity-scale-codec to 2.2.0-rc.2

[Xanewok]

Part of paritytech/substrate#9163.

Needed to bump parity-scale-codec version used by the primitive-types crate, which in turn needs a new version in order to implement a new codec::MaxEncodedLen trait as part of the paritytech/substrate#9163 migration.

[Xanewok]

If we merge this, can we get a release out that contains this PR? If so, can we release straight from master or do we need to add/backport this patch and keep a point release branch from the released 0.6.0?

[ascjones]

Since it is including a pre-release dependency, we would have to make a pre-release version here to prevent users requiring 2.2.0-rc.*

If it was a full 2.2.0 release then it would resolve okay for scale-info 0.6 since the constraint is ^2.0.

I do plan on making a 0.7 release soon (as soon as #96 is merged), so could make a 0.7-rc.0 to include this, if it can wait until early next week?

Otherwise we will have to apply this patch to the 0.6 release commit and make a release just containing this.

Are you able to do:

[patch.crates-io]
scale-info = { git = "https://github.com/paritytech/scale-info", branch = "igor-use-new-codec" }

in the substrate PR for now as a temporary workaround?

[Xanewok]

I do plan on making a 0.7 release soon (as soon as #96 is merged), so could make a 0.7-rc.0 to include this, if it can wait until early next week?

Would you consider releasing 0.7-rc.0 that includes this and possibly release a 0.7-rc.1 shortly afterwards that contain #96? IIUC pre-releases are considered compatible as long as the pre-release opaque tag is the same (so -rc.1 is considered an upgrade over -rc.0). If 0.7.0 will include this change and will be released early next week, I think we can wait until then.

Are you able to do:

We're using patches already in paritytech/substrate#9163 to test if everything works together nicely but since the goal is to unbreak and resume publishing of the Substrate crates, I'm trying to bump the transitive dependency versions and release them to only depend on crates.io-released stuff.

[ascjones]

Would you consider releasing 0.7-rc.0 that includes this and possibly release a 0.7-rc.1 shortly afterwards that contain #96? IIUC pre-releases are considered compatible as long as the pre-release opaque tag is the same (so -rc.1 is considered an upgrade over -rc.0).

If I'm unable to get #96 merged by tomorrow then I will do an interim 0.7-rc release.

If 0.7.0 will include this change and will be released early next week, I think we can wait until then.

Note that I won't do an 0.7.0 which includes this pre-release dependency, so it will remain a pre-release until 2.2.0-rc becomes 2.2.0.

[Xanewok]

Yeah, that makes perfect sense. Thanks!

[ascjones]

Working towards getting a release out today or early next week

[ascjones]

#104

Though I'm considering releasing 0.7.0 without this and then doing a quick follow up as 0.8.0-rc.0 which will include this, to avoid requiring the new prelease to get the other features from 0.7.0.

I will do the release on Monday.

[Xanewok]

That makes sense. Then, I'll pull the 0.8.0-rc.0 in the primitive-types since that'll be the last element of the puzzle to finish the migration in the Substrate workspace. Please ping me once this is released, thanks!

[ascjones]

Apologies, I am still waiting for another approval to merge #96 in order to do the releases a promised. I could hack together an interim release but it is a bit late in the day for that, and I want to avoid a messy release history as much as possible.

We will resolve this one way or another tomorrow so you can be unblocked on this.

[ascjones]

#105