Follow up of 69d605f410c83235aa7b757445e7d0166fcfe2d9
<sub>fun fact:
The refactor in getreceivedbyaddress actually removes the feature to detect if IsMine() was false. You can check getreceivedbyaddress == 0 and isfloat(getreceivedbyaddress)
Follow up of 69d605f410c83235aa7b757445e7d0166fcfe2d9
<sub>fun fact:
The refactor in getreceivedbyaddress actually removes the feature to detect if IsMine() was false. You can check getreceivedbyaddress == 0 and isfloat(getreceivedbyaddress)
Before:
> getreceivedbyaddress $notMineAddress
< 0
> getreceivedbyaccount none
< 0
> getreceivedbyaccount t2 0
< 1.111e-05
After:
> getreceivedbyaddress $notMineAddress
< 0.00000000
> getreceivedbyaccount none
< 0.00000000
> getreceivedbyaccount t2 0
< 0.00001111
Concept ACK. What's the raw JSON differences? Is this a tiny API change?
What's the raw JSON differences? Is this a tiny API change?
yes, it is two different functions to generate the string. Before it used setFloat and oss << std::setprecision(16) << val;. After, it uses our wrapper function.
I think we should do this (for 0.14) but would require a short part in the release notes.
utACK.
The numbers may be formatted slightly differently, but it's not an API change from the perspective of a client, it still returns a JSON number where a JSON number was returned. No need to mention this in release notes.
release notes
What would I write there?
Let's hope no implementation relies on some numbers being represented by scientific notation. Also note that getreceivedbyaddress (and all other calls) already use ValueFromAmount.
[...] No need to mention this in release notes.
Okay for me. utACK 477777f2503e3a56a267556f0fc5091042d93340
Okay for me.
I think we should be careful to not add too much technical details to the explicit descriptions in the release notes. The release notes are already huge, every major release.
Also remember that every commit/PR already gets a mention with the title.