Fix android build number type inconsistency #648
Conversation
|
Tested on Pixel 2 API 28 emulator. Should be pretty simple since it is just an integer conversion. |
|
Very nice - the callstack react-native bug-squish-a-thon bears fruit in our repo :-). As it happens I was recently all over cross platform versioning. I am confident this change is correct. It is also of course trivial. However, I will be the first to admit my javascript is weak as I'm an old Java dinosaur just getting up to speed now that Javascript has real language capabilities ;-). So let me ask a question - it is my understanding that with type coercion built in to javascript, people that have been using this as an string will see continue having this coerced to a string and thus it is actually somewhat backwards-compatible with the declared type. Is that understanding correct? What if people were using it as an integer? Additionally I believe the types are already documented as string, so people using typescript et al will be unaffected (if anything, happier) I just want to double-check as this would be the difference between flagging it as breaking change or just a patch. Thank you! |
|
If people have been using this as an integer, say: buildNumber == 5 or buildNumber > 5. It will continue working just fine, since the JavaScript with coerce the string to numbers in those cases. Those who have been using it like this: buildNumber === 5 will have issues, since it matches both type & value.
Sent via Superhuman iOS ( https://sprh.mn/?vip=ericlewis777@gmail.com )
…On Fri, Apr 26 2019 at 10:29 PM, < ***@***.*** > wrote:
Very nice - the callstack react-native bug-squish-a-thon bears fruit in my
repo :-). As it happens I was recently all over cross platform versioning.
I am confident this change is correct. It is also of course trivial.
However, I will be the first to admit my javascript is weak as I'm an old
Java dinosaur just getting up to speed now that Javascript has real
language capabilities ;-). So let me ask a question - it is my
understanding that with type coercion built in to javascript, people that
have been using this as an integer will see continue having this coerced
to a string and thus it is actually somewhat backwards-compatible. Is that
understanding correct?
Additionally I believe the types are already documented as string, so
people using typescript et al will be unaffected (if anything, happier)
I just want to double-check as this would be the difference between
flagging it as breaking change or just a patch.
Thank you!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (
#648 (comment)
) , or mute the thread (
https://github.com/notifications/unsubscribe-auth/AAFEVR5GUEWDRXOAAD3XF4TPSO3BBANCNFSM4HI267PA
).
|
|
Ok - in that case this is small, but is a breaking change so it goes in the 2.0 bucket and has to sit unfortunately. We normally release changes super quickly, so I'm sorry to say that, but we have a breaking change queue we have done most of the thinking work on already and I want to batch them up. So consider this "accepted" just pending unrelated work. Thank you very much for the contribution and the '===' clarification |
|
At long last! Rolling through the breaking-change stack now. Thanks again for this |
Description
Fixed issue #214
Parse the return integer from PackageManager in to a string, also returns "0" by default instead of 0.
Compatibility
Checklist
README.mdCHANGELOG.mddeviceinfo.d.ts,deviceinfo.js.flow)web/index.js)