Dangerous versioning scheme

Hi!

I’d like to point out a problem with current versioning scheme that I’ve noticed and learned about it the hard way.

A convention that is getting increasingly common in react-native libraries ecosystem is to avoid submitting native code changes in patch updates, leaving it only for minor and major ones.

This is a convention that Expo follows and, as it turns out, react-native-svg is now broken in SDK 35 due to this commit (https://github.com/react-native-community/react-native-svg/commit/c12d66e77923b9d8e5dc99a2fb81a090f0e38129) released in patch 9.9.7

It is not only a problem with Expo, but with any app using CodePush that would also break if it was pinned to a version with ^ or even ~ and somebody would publish an OTA update after yarning.

[msand]

Then again, if expo allows you to choose react-native-svg version, then they should specify what versions are supported on what sdk, or tell you to build the native bundle yourself. Codepush should have all native dependency versions strictly locked such that you only publish js for the exact version of native deps used. This sounds more like a misconfiguration issue than anything else. The native api isn’t promised to stay the same even for patch version changes, only the public api is promised to stay the same / become more spec conformant.

[msand]

Thanks for pointing this out, haven’t noticed or read about this convention anywhere yet, but makes sense in e.g. the expo and codepush use cases for sure. I think minor versions aren’t very fitting for this, if it’s supposed to communicate that any native code has changes, we should probably stick to major versions, although this will likely make the major version change almost monthly/weekly. Not sure what would be best practise in reality here. Would almost need to split into two modules and have peer dependencies defined.