Develop a strategy regarding backwards compatibility

[Niederb]

We should discuss and document how/if we want to support breaking changes (such as #777) by providing backwards compatibility. Some considerations:

• The code gets cluttered quickly if there are lots of conditional compilation instructions
• Running the testing for each option gets out of hand quickly
  • If one is strict we would also need to run our tests for each supported polkadot version
• Different chains (polkadot, kusama, rococo) might have a different configuration and therefore it would be important for our client

[haerdib]

I wonder if we need to put that much effort into this issue. Do we need to provide backwards compatibility or can users, which run an older node, not simply use an older api-client version? Especially with the new versioning (see #800 for more info), the user can choose which Parity version is needed via the minor version.

[haerdib]

Additionally: In general, the api-client is programmed to be very adaptable. So in the very specific case of the MetadataHashCheck, if someone uses an older version of the GenericAdditionalSigned, one could simply use a self-defined type which does not include the HashCheck. So I don't think we should provide an extra compilation feature to provide backward compatibility.

[Niederb]

I don't think we need to put much effort into this, but it would be nice to document somewhere what we do. It is also not clear to me when we should create a release. Maybe something like:

• Always create a release for a new polkadot release
  • No new releases for polkadot bugfix releases unless there are known issues
• Do not backport features and bugfixes per default. If requested we decide on a case by case basis
• If we change the versioning approach (as discussed in New release names in polkadot-sdk #800 ) we should also make clear that there can be breaking changes in feature releases

[haerdib]

Always create a release for a new polkadot release
No new releases for polkadot bugfix releases unless there are known issues

Agreed. In this case, we can increase the minor version (as discussed in #800 ), publish a new release and push to crates.io.

Do not backport features and bugfixes per default. If requested we decide on a case by case basis

Yes. That would most likely cause too much work for our current budget - our primary goal is that our polkadot-release is compatible with the corresponding polkadot node

If we change the versioning approach (as discussed in #800 ) we should also make clear that there can be breaking changes in feature releases

Totally so. Would the current release strategy with marked breaking changes suffice? ( see releases in https://github.com/scs/substrate-api-client/releases)

[haerdib]

Regarding the current backport with the Merkelized Metadata : This would mean that we remove the build flag in the next polkadot release. Correct?

[Niederb]

Regarding the current backport with the Merkelized Metadata : This would mean that we remove the build flag in the next polkadot release. Correct?

If I understand correctly it is still possible to run a node without this feature:
https://github.com/polkadot-fellows/runtimes/blob/afc36ca73146d7e22887fb11c6631a7129d68dd2/relay/kusama/build.rs#L17
Is the check already deployed and active on polkadot?

Totally so. Would the current release strategy with marked breaking changes suffice? ( see releases in https://github.com/scs/substrate-api-client/releases)

Yes, for a specific release this should suffice. I would still mention it in our backwards compatibility "strategy" though.

[Niederb]

See #809