I'd like to better understand the backwards compatibility of these changes,
and this new major bump of aeson:
On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk
Note that I removed the blaze-builder requirement from aeson-HEAD (it now uses the Builder from bytestring with a fallback to blaze-builder when configured with -fblaze-builder).
Which we'd have to do for this HP, as the bytestring package is 0.10.0.2 from the GHC release. Hence, the blaze-builder requirement would still be there.
I think we're pretty close to a release of aeson-0.7.0.0. It would be great to have this version in the HP since:
I'm concerned about timing. In particular, how long should a new major version bump release be out before one is confident that it won't need a minor rev. (0.7.0.1) soon?
* It includes an important bug fix for the eitherDecodeStrict functions
Well, that seems good. Could that get back ported on top of 0.6.2.1 if we decided to not do a major bump this time?
* It has support for arbitrary precision floating point numbers (as
required by the JSON spec) through the Scientific type.
Well, one can argue if that is what the spec says - but in practice, JSON libraries in other systems don't use arbitrary precision floating point (nor does any JavaScript implementation that I know of). Those issues aside, how does the API evolve? What is the plan for introducing this functionality without breaking existing aeson relying code? aeson's Number constructor points to Number from attoparsec which has only two constructors: I Integer and D Double. Wouldn't introducing a third, or replacing D, break existing uses of aeson? * It removes the ByteString instances since JSON doesn't have support
for binary data (this was brought up during the HP inclusion discussion).
Do we have any usage stats to know if any code uses this show instance? Again, trying to avoid breaking compiling code. Were deprecation notices added to the package at some point? - Mark