Fix version bounds.

[fisx]

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.

[mdimjasevic]

Why putting an upper bound on aeson?

[fisx]

Why putting an upper bound on aeson?

same reason we always put upper version bounds. semantic versioning rules about legal breaking changes.

[pcapriotti]

Probably a stupid question, but couldn't we just get rid of all the version bounds and simply rely on cabal.freeze?

[mdimjasevic]

Probably a stupid question, but couldn't we just get rid of all the version bounds and simply rely on cabal.freeze?

@fisx , I'm curious about the same: can't we address the concern via the freeze file?

[fisx]

not a stupid question, this just goes against the idea of how packages work as self-contained entities, especially library packages. one could argue that we don't make those, and they are not self-contained for many other reasons besides the inconsistently applied version bounds in the cabal files. i just had the urge to clean up a little bit.

i think this discussion is becoming much bigger than this PR, though. :)