Release preparations

[piegamesde]

I'd like to go the path towards making a new release. What are the necessary steps involved apart from checking the change log and bumping the version?

[yorickvP]

@Lucus16 bump. I believe there's some hackage involved.

[Lucus16]

• Check the commit log if anything is missing from the change log.
• Use cabal gen-bounds to see if the bounds can be relaxed (see also Too strict upper bounds #130).
• Bump the version
• Give it a git tag.
• Upload to hackage using cabal sdist. See https://hackage.haskell.org/upload for details.

[Lucus16]

@gromakovsky We can't access buildkite and it doesn't seem to be working. Can you see what's up?

[gromakovsky]

As far as I know, our Buildkite setup doesn't work with PRs from forks and it's not easy to fix.
@piegamesde since I previously granted you write access to this repo, could you please push your branch directly to this repo (not your fork) and open a PR from there? It should work then.

[piegamesde]

#132

[piegamesde]

As far as I know, our Buildkite setup doesn't work with PRs from forks and it's not easy to fix.

Does this mean that the CI doesn't work at all for external contributions?

[Lucus16]

Does this mean that the CI doesn't work at all for external contributions?

IIRC, this is to prevent running untrusted code on serokell machines since buildkite runs builds on your own agents. Once you've checked a commit is not evil, you can push the same commit to a branch on this repo and buildkite will pick it up and I think even report on it in the original PR.

[gromakovsky]

We are slowly moving our repos to use GitHub Actions CI instead of Buildkite, which should support running CI from forks (when someone explicitly approves that). We can migrate this repo too, but I'm not sure if it's a good idea, because our GA setup uses our own infra, which won't be available after this repo is transferred elsewhere. Though, it may work just fine after the transfer, because it shouldn't require much besides nix 🤔