Fix constraint kind when building with newer versions of aeson

[Tristano8]

The definition of KeyValue changed in aeson 2.2.0.0 and has a different constraint kind. This fixes the compilation error in unparseTimestamp

[Tristano8]

@IamfromSpace This fix will need to be included as a metadata revision for all the versions that use unparseTimestamp:
0.4.9, 0.4.10, 0.4.10.1, 1.0.0, 1.0.0.1. I don't think anyone using hal with aeson > 2.2.0.0 is able to build with the current master

[endgame]

I think that's basically right, apart from an = on the bound. Those versions of hal will probably fail to build with aeson >= 2.2.0.0. So we should revise those versions to have aeson < 2.2.0.0. I'm happy to do this in my capacity as a Hackage Trustee, can you reply in the next couple of weeks if you don't want me to do this?

[IamfromSpace]

Thanks everyone for coming together on this!

When kicking off the jobs, it seems as though there's still another 2.2 break, having removed Data.Aeson.Parser. Looks like it's in a separate package now:

Move Data.Aeson.Parser module into separate attoparsec-aeson package, as these parsers are not used by aeson itself anymore.

I think this is a great approach though. If we focus on expanding the bounds for 1.0.x and 4.9.x then that should be best for everyone--just give people something they can safely to move to without incurring migration costs. I'll look into adding constraints though just to keep things tidy.

Tomorrow PST afternoon I should have time to really sink into this. I'll look into back-porting and adding constraints.

[endgame]

Sounds good, thanks for looking into this so quickly.

Re: Data.Aeson.Parser: if you depend on attoparsec-aeson right now, it'll lock you to aeson >= 2.2.0.0 && <2.3. An empty compatibility package is in the works: haskell/aeson#1048

I've been watching a few packages deal with the 2.2.0.0 change. I think the best thing for us to do is to add wait for the compatibility release of attoparsec-aeson to come out, add a dependency on it in this PR once we know what bounds to use, and then cut 1.0.0.2 with a nice wide aeson bound (probably ^>=1.5.6.0 || >=2.0 && <2.3).

Since Hackage metadata revisions can't attach additional dependencies to existing releases, the versions 0.4.9, 0.4.10, 0.4.10.1, 1.0.0, and 1.0.0.1 should probably just get revised to aeson <2.2.0.0. Let me know if you'd like me to do this.

[IamfromSpace]

Ah, @endgame that's a good call out on getting locked into >=2.2 with the new package. That's great that the compatibility package is in the works, and totally agree with your analysis then. Hopefully that comes out soon.

I'll start tackling the revisions now, but if they're not done by tomorrow, then your help would be appreciated! Don't want these bounds to be longer than they have to.

[IamfromSpace]

Everything should now be correctly constrained everywhere, git, tags, branches, hackage. Hopefully i didn't miss anything, it all gets a bit fiddly with that many things. @endgame if I did miss something, please feel free to fix it. Hopefully everything that we expect to work now is.

@Tristano8 apologies for the merge conflict, should be easy one to fix though! Also, for easier back porting, the ideal spot to branch off of might be from 0.4.10.1, so we can eventually release a 0.4.11 which supports aeson 2.3. i'm happy to lend a hand with how to do that, or I can adjust the commits once you're done here on master (leaving your name on them, of course).

[endgame]

@IamfromSpace hackage revisions look correct. Thank you for doing them!

[Tristano8]

Closing this in favour of #122