Skip to content

Release process

Anton Latukha edited this page Nov 2, 2020 · 7 revisions
  • Please note that after making a GitHub release - CI triggers the additional pipelines, that at the moment of writing - test classical Cabal builds on GHCs GHC 8.6, 8.8 (to be solidly sure that Hackage would successfully build those). To cut the CI loop for development - some (as much as possible) CI tests and actions divert to testing once on pre/release trigger.

  • So it is a good idea to form a pre-release.

    • To do that CI builds.
    • In the meantime to not forget to update the Cabal metadata before making a Git tag.
  • Docs currently need to be compiled and uploaded manually:

set -e

dir=$(mktemp -d /tmp/dist-docs.XXXXXX)
trap 'rm -r "$dir"' EXIT

# assumes cabal 2.4 or later
cabal v2-haddock --builddir="$dir" --haddock-for-hackage --enable-doc

# (pasting pass does not work) Enter _by hand_: account, password
cabal upload -d --publish $dir/*-docs.tar.gz
  • After the release, Nix default.nix rev should be updated. It is risky to update rev right before publishing Hackage release - rev would be recommended without testing, so it is a good idea to update it after the release, so dev envs update and rev gets tested during development.
Clone this wiki locally