... | ... | @@ -8,23 +8,16 @@ |
|
|
|
|
|
## Core libraries
|
|
|
|
|
|
|
|
|
|
|
|
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](working-conventions/boot-libraries) for details.
|
|
|
|
|
|
|
|
|
## Test policy
|
|
|
|
|
|
|
|
|
- Run `./validate --slow` on all [tier 1 platforms](platforms) before release.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Branching the tree
|
|
|
|
|
|
|
|
|
Recommended procedure for a clean Git history:
|
|
|
|
|
|
1. 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
|
... | ... | @@ -35,20 +28,18 @@ Recommended procedure for a clean Git history: |
|
|
|
|
|
![](making-releases/branch-example.png)
|
|
|
|
|
|
|
|
|
Example for result of branching procedure described above
|
|
|
|
|
|
## Make release notes
|
|
|
|
|
|
## 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.
|
... | ... | @@ -59,24 +50,22 @@ It's also good practice to update the `config.guess` and `config.sub` files scat |
|
|
|
|
|
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
|
|
|
|
|
|
## Tagging the release
|
|
|
|
|
|
Create a signed annotated git tag,
|
|
|
|
|
|
```wiki
|
|
|
```
|
|
|
$ git tag -asu "Benjamin Gamari <ben@well-typed.com>" 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
|
|
|
|
|
|
## 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](building/getting-the-sources#getting-a-branch), and ensure that the version number and `RELEASE` near the top of `configure.ac` are correct. Then:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -87,22 +76,19 @@ $ 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
|
|
|
|
|
|
## 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
|
|
|
|
|
|
## Making the binary builds
|
|
|
|
|
|
We currently produce binary distributions for the following environments,
|
|
|
|
... | ... | @@ -116,17 +102,14 @@ We currently produce binary distributions for the following environments, |
|
|
- amd64/FreeBSD 11
|
|
|
- amd64/OpenBSD 6.2
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
- [Sphinx](http://www.sphinx-doc.org/)
|
|
|
- HsColour (cabal install hscolour)
|
|
|
- [xelatex](http://xetex.sourceforge.net/)
|
|
|
|
|
|
|
|
|
A good sanity check is to check the output of `configure` and make sure all of the tool fields are filled out.
|
|
|
|
|
|
|
|
|
Untar the `src` tarball. Then:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -140,10 +123,8 @@ BeConservative=YES |
|
|
EOF
|
|
|
```
|
|
|
|
|
|
|
|
|
(Note that `BeConservative` is only relevant on Linux, as it controls usage of `clock_gettime` in the RTS.)
|
|
|
|
|
|
|
|
|
Then:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -152,11 +133,10 @@ $ make 2>&1 | tee ../make.log |
|
|
$ make binary-dist 2>&1 | tee ../bd.log
|
|
|
```
|
|
|
|
|
|
|
|
|
Nightly builders will automatically produce release builds on FreeBSD, putting the results [here](http://haskell.inf.elte.hu/ghc/dist/freebsd8/).
|
|
|
|
|
|
## Sanity checking the binary builds
|
|
|
|
|
|
## Sanity checking the binary builds
|
|
|
|
|
|
The `compare` tool compares the tarballs of different releases, and warns about possible problems:
|
|
|
|
... | ... | @@ -169,8 +149,8 @@ $ make |
|
|
$ <</path/to/ghc/tree>>/distrib/compare/compare <<previous_release_files>> <<this_release_files>>
|
|
|
```
|
|
|
|
|
|
## Check that the build can build the release
|
|
|
|
|
|
## Check that the build can build the release
|
|
|
|
|
|
Install the release, set your `$PATH`, then just untar and:
|
|
|
|
... | ... | @@ -179,8 +159,8 @@ $ ./configure |
|
|
$ make
|
|
|
```
|
|
|
|
|
|
## Sign and hash the release artifacts
|
|
|
|
|
|
## Sign and hash the release artifacts
|
|
|
|
|
|
To ensure that users can verify the authenticity of downloaded release artifacts, we offer detached gpg signatures and SHA{1,256} hashes of the tarballs. These are generated with,
|
|
|
|
... | ... | @@ -190,7 +170,6 @@ $ sha1sum *.tar.xz > SHA1SUMS |
|
|
$ gpg -u 'Benjamin Gamari <ben@well-typed.com>' --detach-sign *.tar.xz SHA1SUMS SHA256SUMS
|
|
|
```
|
|
|
|
|
|
|
|
|
Be sure that your public key has been uploaded to a few well-known public keyservers.
|
|
|
|
|
|
## Create and upload the library documentation
|
... | ... | @@ -213,40 +192,35 @@ haskell.org$ mv ../index.html . |
|
|
haskell.org$ for i in ../*.tar.bz2; do tar -jxf $i; done
|
|
|
```
|
|
|
|
|
|
|
|
|
Sanity check `http://www.haskell.org/ghc/docs/<<VERSION>>/`. In particular, check that the libraries docs include both Win32 and unix.
|
|
|
|
|
|
## Prepare the webpage
|
|
|
|
|
|
## Prepare the webpage
|
|
|
|
|
|
In the `http://www.github.com/haskell-infra/ghc-homepage` git repository, create a `download_ghc_<<MANGLED_VERSION>>.shtml` page based on the previous one.
|
|
|
|
|
|
|
|
|
Sanity check `http://www.haskell.org/ghc/download_ghc_<<MANGLED_VERSION>>`. In particular, check that the release notes and documentation links work. Ensure release is in "news" section of `index.html`.
|
|
|
|
|
|
|
|
|
Push your changes to `webhost.haskell.org` (TODO site should pull from git repo).
|
|
|
|
|
|
|
|
|
## Upload the binaries
|
|
|
|
|
|
```wiki
|
|
|
scp -r 7.6.2 haskell.org:/srv/web/haskell.org/ghc/dist/
|
|
|
```
|
|
|
|
|
|
|
|
|
Sanity check that the download links work.
|
|
|
|
|
|
- Update `http://downloads.haskell.org/~ghc/latest/`.
|
|
|
|
|
|
## Announcing
|
|
|
|
|
|
## Announcing
|
|
|
|
|
|
Add the release to "Versions" in the trac admin section, and make it the default version.
|
|
|
|
|
|
|
|
|
Update "Current Stable Release" in `download.shtml`, and move the previous release down to "Older Releases".
|
|
|
|
|
|
|
|
|
Update "Latest News" in `index.shtml`.
|
|
|
|
|
|
```wiki
|
... | ... | @@ -254,17 +228,14 @@ haskell.org$ ~/mk-latest-links |
|
|
haskell.org$ ~/mk-latest-links | sh
|
|
|
```
|
|
|
|
|
|
|
|
|
Update the `ANNOUNCE` file.
|
|
|
|
|
|
|
|
|
Mail `ANNOUNCE` with the subject `[ANNOUNCE] GHC version $version` to,
|
|
|
|
|
|
```wiki
|
|
|
glasgow-haskell-users@haskell.org, haskell@haskell.org, ghc-devs@haskell.org, haskell-cafe@haskell.org
|
|
|
```
|
|
|
|
|
|
|
|
|
For an RC, a smaller message is sent to just `glasgow-haskell-users@haskell.org`, e.g.:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -282,8 +253,8 @@ Please test as much as possible; bugs are much cheaper if we find them |
|
|
before the release!
|
|
|
```
|
|
|
|
|
|
## Post-release book-keeping
|
|
|
|
|
|
## Post-release book-keeping
|
|
|
|
|
|
There are a variety of things that should also be done,
|
|
|
|
... | ... | @@ -298,14 +269,11 @@ 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`.
|
|
|
|
|
|
## Uploading libraries
|
|
|
|
|
|
|
|
|
## Uploading libraries
|
|
|
|
|
|
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:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -320,5 +288,4 @@ $ git submodule | grep -F -- '-g' |
|
|
c16032d83c8ce7ac3e11b99f8e80bfdfc77f0d1f utils/hsc2hs (2009-06-25-87-gc16032d)
|
|
|
```
|
|
|
|
|
|
|
|
|
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. |