Release candidates should be numbered with the patch-level preceding their release. For instance, the first release candidate for 8.0.1 should be versioned 8.0.0-rc1
A few weeks before the first alpha release the release manager should contact the core library upstream maintainers to determine which core library versions will ship with the new GHC release. See WorkingConventions/BootLibraries for details.
Prepare a wip-branch for bumping to the next stable GHC version (NB: You have to update configure.ac to a 3-component version, i.e. to [8.0.0] rather than [8.0]!). Do *not* push this branch to a non-wip branch until 1. has been pushed
After you succeeded with 1., try to rebase your stable wip branch to the commit right before the GHC HEAD version bump.
If both worked, and nobody disturbed master in the mean-time, push master, and then push the new stable ghc-x.y branch. If master changed, rebase and go back to step 1.
create an annotated ghc-x.yy-start tag pointing to the commit prepared in step 1.
Example for result of branching procedure described above
Make release notes
In docs/users_guide, add a $VERSION-notes.rst file and write the release notes.
Add a corresponding entry to the table-of-contents in index.rst.
Ensure that the changelogs in libraries/* are up-to-date. In particular note that several of the packages included in the ghc tree have their versions tied to ghc's version. Find these with git grep libraries/ ProjectVersion and ensure their changelogs include the new version.
Updating the tree
Update the ANNOUNCE file in the root of the tree.
In the AC_INIT line of configure.ac, set the version number. A few lines below, set RELEASE=YES.
It's also good practice to update the config.guess and config.sub files scattered about the tree (currently in the root, libraries/base, and libraries/integer-gmp) from upstream (config.guess, config.sub). These can be easily updated by running the update-autoconf.shscript in ghc-utils from the root of the source tree.
You may also want to update the llvm-targets file: utils/llvm-targets/gen-data-layout.sh > llvm-targets. Note that non-Apple clang releases lack the iOS targets so be sure to preserve these.
Tagging the release
Create a signed annotated git tag,
$ git tag -asu "Benjamin Gamari <firstname.lastname@example.org>" ghc-8.4.3-release HEAD
In the case of release candidates an unannotated tag is sufficient (e.g. git tag ghc-7.10.2-rc1 HEAD).
Making the source tarball
The source tarball includes some generated files, such as Parser.hs (generated from Parser.y.pp). We therefore need to do a build before generating the source tarball.
First check out the branch, and ensure that the version number and RELEASE near the top of configure.ac are correct. Then:
$ perl boot$ ./configure$ ./mk/get-win32-tarballs.sh download all # ensure all Windows tarballs are available$ make # GHC <= 7.10 only$ make sdist
It is advisable to use a machine with as recent an autoreconf as possible; in particular, 2.61 is known to make a configure script that doesn't work on Windows.
You should now have source tarballs sdistprep/ghc-<VERSION>-src.tar.bz2 and sdistprep/ghc-<VERSION>-testsuite.tar.bz2.
N.B. the lndir utility required by make sdist is provided by xutils-dev on Debian.
Sending it to binary packagers
We are lucky to have a dedicated set of contributors who build binary distributions for platforms which GHC HQ does not handle. Since 8.0.1-rc3 our policy has been to provide source distributions to binary packagers seven days before the final release. We do this in order to put these externally-provided distributions on equal footing with the GHC-HQ-provided distributions.
Making the binary builds
We currently produce binary distributions for the following environments,
i386/Linux (Debian 8)
amd64/Linux (Debian 8)
amd64/Linux (Debian 8 with DWARF)
amd64/Linux (Debian 9)
First, you should make sure your environment has all of the tools necessary to make a proper release build. This can include more tools than an "ordinary" build of GHC requires, since documentation requires extra tools. You will need:
For an RC, a smaller message is sent to just email@example.com, e.g.:
Subject: ANNOUNCE: GHC x.y.z Release Candidate 1We are pleased to announce the first release candidate for GHC x.y.z: http://www.haskell.org/ghc/dist/x.y.z-rc1/This includes the source tarball and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64.We plan to make the x.y.z release <sometime>.Please test as much as possible; bugs are much cheaper if we find thembefore the release!
There are a variety of things that should also be done,
If major release: Update the FP_COMPARE_VERSIONS([$GhcVersion], ...) check in configure.ac
Update the latest symlinks on downloads.haskell.org.
TODO FIXME Normally Herbert and upstream maintainers take care of this - we always attempt to have full releases for all package by the time the final release happens (although not necessarily so for an RC - they may ship slight interim states).
Heuristic for detecting submodule libraries which have no proper release:
The listing above shows submodules which point to submodules that have no *annotated* tag, and which need further investigation. In some cases the tag just wasn't propagated from the upstream repo into our local Git mirror.