belemaire
commented
3 years ago @friederbluemle Yes there is no ideal solution here. I chose 100 as custom patch version as I'm pretty confident no patch releases of React Native will reach this point, given their release history.
Idea I had in mind is as you mention, releasing new versions from 100 and onward for any new official patch release of the version line or custom additional ern changes. We should document these custom releases on our GitHub fork (via standard GH release tag description) to indicate of which version (patch) they are cut off.
On client side, it might be better (or we could suggest it in documentation) to use the + placeholder (even if not super recommended, in this context should be fine) not to have to account for every new 100+ releases. (i.e if your application is using 0.64 RN, just use version 0.64.+, which will get the latest of 100 line including any propagated official patch releases of this version line -as I don't see any reason not to always be on latest patch update for RN-)
See documentation update part of this PR for additional details.
Please note that this solution for dynamic feature module support has been tested is already working in production for one of our internal client teams. Custom AARs
0.63.100and0.64.100are already available.Even though we really didn't want to have to fork react native, there was unfortunately no other way to fix this issue. That being said, the fork for now is only limited to this change for dynamic feature modules support, and only for android react native library. We are not planning any other custom modifications. Hopefully if we get to have these changes pushed to react native (will require some refactoring to make it cleaner), we may get rid of the fork and this mechanism (still this is debatable, in case we need some urgent fix that may take a while to get through official RN release, this might still come in handy).