Restore ink! 3.x.x backward compatibility

[agryaznov]

This issue describes the reasons of this StackExchange reported problem with ink! v3.0.1

Cargo crate dependencies version specifications rules work as follows:
3.0.1 := >= 3.0.1 < 4.0.0

This leads to that 3.2.0 is being the resolved version even when =3.0.1 is specified in the contract manifest, for the following crates:

• ink_allocator
• ink_engine
• ink_lang_codegen
• ink_lang_ir
• ink_prelude
• ink_storage_derive

As a hotfix for this, I've changed the dependencies to be specified as tilde requirements. I suggest making release v3.0.2 out of it.

Meanwhile, it is all really seems to me to be just about stitching to SemVer rules. E.g. 3.2.0 should have been backward compatible to 3.0.1, if it's not then it should have been versioned 4.0.1, instead. If these rules were followed, there would not be the need to apply tilde requirements as cargo is SemVer compatible by default. So maybe it worth re-considering ink! versioning policy more rigorously.

Other questions to regard on this topic:

1. Why should we really increment examples/ contracts manifest versions without actually changing the contract sources itself at all?
2. The workflow described here does not imply fixing older releases like issuing v3.0.2 containing hotfix for v3.0.1.
   But it turns out we still should make such releases to support older versions being used by contract developers, as e.g. to fix such issues as being reported in the aforementioned SE question.

[athei]

This leads to that 3.2.0 is being the resolved version even when =3.0.1 is specified in the contract manifest, for the following crates:

=3.0.1 will only ever resolve to 3.0.1. But we don't use the = in our manifests anywhere.

As a hotfix for this, I've changed the dependencies to be specified as tilde requirements. I suggest making release v3.0.2 out of it.

Please don't. Tilde is very uncommon.

Meanwhile, it is all really seems to me to be just about stitching to SemVer rules. E.g. 3.2.0 should have been backward compatible to 3.0.1, if it's not then it should have been versioned 4.0.1, instead. If these rules were followed, there would not be the need to apply tilde requirements as cargo is SemVer compatible by default. So maybe it worth re-considering ink! versioning policy more rigorously.

Depends on how you define the scope of semver. When just looking at the crate this is a minor release because it just adds new functionality and the old code still compiles. If you say it is also about being compatible to old pallet-contracts versions then, yes, it should have been a major release. However, I don't think this is really feasible: There is no semver on the substrate side where we could sync it to.

[agryaznov]

=3.0.1 will only ever resolve to 3.0.1. But we don't use the = in our manifests anywhere.

The origin was in this recommendation to specify =3.0.1 in contract manifest (again, to make it possible to build contract with particular ink! and pallet versions). This then leads to e.g. getting inv_env 3.0.1 and that, it turn, gets ink_allocator 3.2.0 because it has its dependency specified as ink_allocator = { version = "3.0.1"... in its manifest, which resolves to 3.2.0 bc of the aforementioned rule (3.0.1 := >= 3.0.1 < 4.0.0). And then guess what, the contract won't compile because 3.2.0 is not compatible with 3.0.1...

Please don't. Tilde is very uncommon.

I agree, but what are the other options for solving this then?

If you say it is also about being compatible to old pallet-contracts versions then, yes, it should have been a major release.
However, I don't think this is really feasible: There is no semver on the substrate side where we could sync it to.

What do you think about making it in this logic?: if the release being issued is still compatible with the same pallet_contracts version as the current MAJOR ink! version works with, than it's a MINOR (or PATCH) release. Otherwise, it's a new MAJOR one.

[athei]

What do you think about making it in this logic?: if the release being issued is still compatible with the same pallet_contracts version as the current MAJOR ink! version works with, than it's a MINOR (or PATCH) release. Otherwise, it's a new MAJOR one.

This would make us go through major versions very quickly. We want to be able to add functionality in a backwards compatible way without issuing a new major version. What happened here was just a mistake. We made existing code require a new pallet-contracts: We didn't just add but replaced the existing seal_set_storage by a new version. If we would still be using the old version for the existing Mapping::set and the new version for Mapping::contains than a minor release wouldn't have been a big issue.

[agryaznov]

So the changes that made 3.1.0 backward incompatible with the elder node version (0.13.0) are reverted in this branch and the MINOR ink! 3.3.0 release is planned.

[dndll]

Is there any plan to yank 3.0.0 and publish a patch with ink_lang_codegen as a fixed dependency? I only just found this after spending some time on it.

[agryaznov]

The 3.3.0 release is on its way to fix these issues.

[dndll]

The 3.3.0 release is on its way to fix these issues.

I think this solves the problem for users on 3.3.0. Not for 3.0.0, right?

Would it not also be useful for users facing the same issue to:

• at least have a quick note on < 3.3.0 releases to override the ink_lang_codegen crate
• better still, yank the defective crate and publish a patch that fixes it without having users override the crate themselves

Personally, I think users may not want to blindly update to another minor version, as it stands the only place to find this issue is in this issue, which another release does not necessarily resolve the matter for users on 3.0.0.

[agryaznov]

As cargo sticks to SemVer on dependency crates version resolution, after ink! 3.3.0 is published, even users of 3.0.0 should become getting ink_lang_codegen 3.3.0, without overriding the crate themselves.

The backwards compatibility breaking changes described (and fixed) in the #1284 were introduced not in 3.0.0 but in 3.1.0 and fixed in 3.3.0 minor release in accordance to the SemVer practices.

[agryaznov]

Solved by #1284