Bump bounds for cryptonite and memory

cdepillabout commented 2 years ago

The version bounds need to be bumped for cryptonite and memory:

I removed the upper version bounds instead of bumping them. My justifications for this:

cryptonite and memory are relatively stable packages. There aren't too many huge breaking changes. My guess is that it will be less work for us to add hackage revisions whenever we do happen to encounter breaking changes (rather than having to add a hackage revision every couple of months when new versions get released, along with an accompanying PR).
We only use a small part of the entire cryptonite and memory APIs, so it is likely that we won't be affected even if there is a breaking change.

In the meantime, I added revisions for password and password-types to bump the version bounds. In these revisions, I did end up keeping the upper version bounds, just bumping them:

cdepillabout commented 2 years ago

I had tried to add GHC-9.2 to CI in 60237be, but there were various problems and I ended up giving up on this.

Vlix commented 2 years ago

Seems like a solid plan. We can also just remove the upper bounds via hackage revisions, so no need to make another release.

If at some point there's a serious breaking change, we might add revisions to hackage that then limit previous releases it to the last compatible cryptonite/memory version, and then continue with no upper bounds from the fixed password releases, I guess?

Also, I would have liked to see what the problem was with GHC 9.2, but I'm assuming it's just some packages not adjusted for GHC 9.2?

cdepillabout commented 2 years ago

Also, I would have liked to see what the problem was with GHC 9.2, but I'm assuming it's just some packages not adjusted for GHC 9.2?

Here's the CI run:

https://github.com/cdepillabout/password/runs/5534246236?check_suite_focus=true

The above error is just a problem with password for having a too-strict dependency on bytestring, but even if you remove that, it looks like the base64 package we are using has not been updated to work with GHC-9.2.

We can also just remove the upper bounds via hackage revisions, so no need to make another release.

That sounds good. I'll do that now:

If at some point there's a serious breaking change, we might add revisions to hackage that then limit previous releases it to the last compatible cryptonite/memory version, and then continue with no upper bounds from the fixed password releases, I guess?

That's basically what I was thinking!

We also have the possibility of going back to having upper bounds in our repo if we don't want the maintenance burden of always keeping up with newer cryptonite/memory versions. Although I guess in practice we will probably want to keep up with the latest cryptonite/memory versions.

Vlix commented 2 years ago

Ah, bytestring. Yeah I bumped that recently in the safe-json package as well. Didn't really encounter any breaks, so I think it should be pretty painless to bump it. I think one of us can just try that out at some point, shouldn't be too difficult.

Our base64 dependecy is at least updated to allow for bytestring <= 0.12, so I wonder 🤔

cdepillabout / password

Bump bounds for cryptonite and memory #57