@@ -1,119 +0,0 @@
1−0.7.0.0
2−
3− * The performance of encoding to and decoding of bytestrings
4− have both improved by up to 2x, while also using less
5− memory.
6−
7− * New dependency: the scientific package lets us parse
8− floating point numbers more quickly and accurately.
9−
10− * eitherDecode, decodeStrictWith: fixed bugs.
11−
12− * Added FromJSON and ToJSON instances for Tree and Scientific.
13−
14− * Fixed the ToJSON instances for UTCTime and ZonedTime.
15−
16−0.6 series
17−
18− * Much improved documentation.
19−
20− * Angle brackets are now escaped in JSON strings, to help avoid XSS
21− attacks.
22−
23− * Fixed up handling of nullary constructors when using generic
24− encoding.
25−
26− * Added ToJSON/FromJSON instances for:
27−
28− * The Fixed class
29− * ISO-8601 dates: UTCTime, ZonedTime, and TimeZone
30−
31− * Added accessor functions for inspecting Values.
32−
33− * Added eitherDecode function that returns an error message if
34− decoding fails.
35−
36−0.5 to 0.6
37−
38− * This release introduces a slightly obscure, but
39− backwards-incompatible, change.
40−
41− In the generic APIs of versions 0.4 and 0.5, fields whose
42− names began with a "_" character would have this character
43− removed. This no longer occurs, as it was both buggy and
44− surprising (https://github.com/bos/aeson/issues/53).
45−
46− * Fixed a bug in generic decoding of nullary constructors
47− (https://github.com/bos/aeson/issues/62).
48−
49−0.4 to 0.5
50−
51− * When used with the UTF-8 encoding performance improvements
52− introduced in version 0.11.1.12 of the text package, this
53− release improves aeson's JSON encoding performance by 33%
54− relative to aeson 0.4.
55−
56− As part of achieving this improvement, an API change was
57− necessary. The fromValue function in the
58− Data.Aeson.Encode module now uses the text package's
59− Builder type instead of the blaze-builder package's
60− Builder type.
61−
62−0.3 to 0.4
63−
64− * The new decode function complements the longstanding
65− encode function, and makes the API simpler.
66−
67− * New examples make it easier to learn to use the package
68− (https://github.com/bos/aeson/tree/master/examples).
69−
70− * Generics support
71−
72− aeson's support for data-type generic programming makes it
73− possible to use JSON encodings of most data types without
74− writing any boilerplate instances.
75−
76− Thanks to Bas Van Dijk, aeson now supports the two major
77− schemes for doing datatype-generic programming:
78−
79− * the modern mechanism, built into GHC itself
80− (http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html)
81−
82− * the older mechanism, based on SYB (aka "scrap your
83− boilerplate")
84−
85− The modern GHC-based generic mechanism is fast and terse: in
86− fact, its performance is generally comparable in performance
87− to hand-written and TH-derived ToJSON and FromJSON
88− instances. To see how to use GHC generics, refer to
89− examples/Generic.hs.
90−
91− The SYB-based generics support lives in Data.Aeson.Generic
92− and is provided mainly for users of GHC older than 7.2. SYB
93− is far slower (by about 10x) than the more modern generic
94− mechanism. To see how to use SYB generics, refer to
95− examples/GenericSYB.hs.
96−
97− * We switched the intermediate representation of JSON objects
98− from Data.Map to Data.HashMap which has improved type
99− conversion performance.
100−
101− * Instances of ToJSON and FromJSON for tuples are between 45%
102− and 70% faster than in 0.3.
103−
104− * Evaluation control
105−
106− This version of aeson makes explicit the decoupling between
107− *identifying* an element of a JSON document and *converting*
108− it to Haskell. See the Data.Aeson.Parser documentation for
109− details.
110−
111− The normal aeson decode function performs identification
112− strictly, but defers conversion until needed. This can
113− result in improved performance (e.g. if the results of some
114− conversions are never needed), but at a cost in increased
115− memory consumption.
116−
117− The new decode' function performs identification and
118− conversion immediately. This incurs an up-front cost in CPU
119− cycles, but reduces reduce memory consumption.