New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(android): making rn >= 73 support also compatible with rn <= 66 #676
fix(android): making rn >= 73 support also compatible with rn <= 66 #676
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not trying to be rude but I have a bunch of libraries I could fix so I want to understand this technically.
How exactly is the previous PR not proper backwards compatibility and how exactly is this conditional inclusion of the namespace now proper backwards compatibility?
When Is say exact, I'm interested in the user experience library consumers will have when integrating the totally unpatched version, the previous PR version, and the version with this PR when they are using rn69, rn71 and rn73 to make sure I understand who exactly is affected by what
If I find some time in the next days, I will create a sample project using the latest netinfo version. |
It's possible - if this is needed for gradle6 - that this is already an inadvertently breaking change. I'll do a quick If I were a betting person, I would bet that we have blown it up, and your PR here is the proper fix. I just need to understand it well (edit: looks like rn66 was the first one to include a bump to gradle 6.9 so it is a good target facebook/react-native@547b4c9 ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having read a bit more and looked at a few more styles, I think this is at minimum necessary here in order to not break people on react-native 66 and below, and it is compatible with others.
I've seen one other trick using groovy code to inhale the AndroidManifest and replace the package out of it (to quiet the warning...) but I don't like that one as it requires writable filesystems and seems fussy.
This should be good to go, I am keen to understand this whole thing better but I truly appreciate the help regardless. Cheers
## [9.4.1](v9.4.0...v9.4.1) (2023-06-29) ### Bug Fixes * **android:** making rn >= 73 support also compatible with rn <= 66 ([#676](#676)) ([0c053eb](0c053eb))
🎉 This PR is included in version 9.4.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Overview
Follow-up from #675. This ensure proper backwards-compability to older react-native and gradle versions.
Test Plan