v1.0.0.0 planning

[bergmark]

in suggested merge order:

• TaggedObject encoding for Nullary constructor includes "contents" #300 via TaggedObject encoding for Nullary constructor does not have "contents" field #307 Removing contents field for nullary constructors
• Investigate whether TaggedObject encoding for Nullary constructor does not have "contents" field #307 is/can be made a non-breaking change (no since the encode output changes, but "contents" : [] is luckily still accepted when parsing)
• Fix a bug with generics and single-field records #366 Fix a bug with generics and single-field records
• ToJSON1 & FromJSON1 #352 via Add lifted typeclasses and some instances #381 Lifted type classes
• overlapping instances for [Char] #351 via List instance #382 stop using overlapping instances for strings
• Generalise FromJSON (Map k v) instances #289 via Even more general map serialising #341 Generalized map serialization
• Higherkinded special strings #391 Modify higher kinded typeclasses from Add lifted typeclasses and some instances #381
• Invalid JSON generated by genericToEncoding #387 Fix omitNothingFields + genericToEncoding via Fix issue #387 with encoding using omitNothingFields #394
• JSONPath isn't tracked in autoderived instances #357 JSONPath isn't tracked in autoderived instances (TH & generics) via Track JSONPath in autoderived parsers. Fixes #357 #398
• FromJSON/ToJSON instances in haddocks #375 Improve haddocks by not using orphan instances
• Generics for Higher kinded type classes via Generics and TH support for lifted typeclasses #414 and Fromjson1 th generics backup no orphans #415
• Add documentation on how to use/write ToJSONKey (etc) instances. @andrewthad
• Finalise encoding refactoring @phadej
• Add notes on all these checklist items to the changelog @bergmark
• Write tests for lifted typeclasses and their generic/th derivations @phadej
• Do some stackage/Silk testing @bergmark
• Fix recently added TODOs
• Do not truncate Integral values #317 Do not accept and truncate floats to integrals

Please give feedback if I missed something!

[bergmark]

@andrewthad @phadej should we start by merging the lifted type classes next?

[andrewthad]

Yeah, I think that that one is the best place to start since it was rebased on top of master like a week ago.

[RyanGlScott]

We should probably add generics/TH support for the lifted typeclasses to this list. I haven't made an issue for it, since I was hoping it could be a part of #352, but I dropped the ball.

[andrewthad]

@RyanGlScott If I understand correctly, the generics/TH support is a non-breaking change. Even if it were added after the 0.12 release, I think it would only require bumping minor version. If it's something that you can do in under a week, I don't think that anyone would object to you adding it for the 0.12 release though.

[andrewthad]

Also @bergmark, I'd still like to redo the module merge from #375 to eliminate orphan instances. I think that now is probably a good time to do that. Let me know if you agree and I'll do it.

[andrewthad]

Nevermind, I just noticed #412

[andrewthad]

Down to one final checkbox. I'll add the docs for using ToJSONKey and friends.

[bergmark]

before i added another one ;-) But thanks!

I'll do the changelog later.

[phadej]

I'd like to finalise my Encoding related refactoring and write tests to lifted typeclasses and their generic/th derivations

[phadej]

Few more points:

write Key instance to at least numeric and datetime types, then the ones I'd personally need would be covered. I can do it while making Encoding related refactorings, as they would be easy to add next to ToJSON and FromJSON instances.

I'd like to see what needed to be exported to write instance for InsOrdHashMap using new aeson's ToJSONKey and FromJSONKey functionality

[bergmark]

@andrewthad Did you consider error messages for FromJSONKey? I suppose this wasn't needed before. It would be super nice if we had JSONPath error messages here as well

[andrewthad]

I hadn't considered that. I haven't really worked with the JSONPath parts of aeson before, so I don't know how they work. Currently, we can get errors like this:

>>> eitherDecode "{\"hey\": {\"foo\": \"not_number\"}}" :: Either String (M.Map Text (M.Map Text Int))
Left "Error in $.hey.foo: expected Int, encountered String"

Which is good. If we instead expect an Int key, we get:

>>> eitherDecode "{\"hey\": {\"foo\": \"ht\"}}" :: Either String (M.Map Text (M.Map Int Int))
Left "Error in $.hey: input does not start with a digit"

What error would we expect instead?

[phadej]

@andrewthad @bergmark #423