Develop a strategy regarding backwards compatibility

scs / substrate-api-client

Library for connecting to substrate API over WebSockets

Apache License 2.0

259 stars 122 forks source link

Develop a strategy regarding backwards compatibility #788

Open Niederb opened 2 months ago

Niederb commented 2 months ago

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 commented 3 days ago

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 commented 2 days ago

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.