GHC

The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at ​https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release ... [More] , fixing numerous regressions and bugs present in GHC 8.4.1. These include: A regression resulting in some uses of Control.Exception.evaluate to be inappropriately optimised away (see #13930) A regression resulting in segmentation faults of programs compiled with profiling (#14705) A bug causing runtime system panics while running programs with retainer profiling (#14947) The configure scripts now accepts a --disable-dtrace option, again allowing GHC to be bootstrapped on FreeBSD (#15040) The version number of the base package has been bumped to 4.11.1.0 to reflect the addition of the GHC.IO.FixIOException type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, ​https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_4_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at ​https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release ... [More] , fixing numerous regressions and bugs present in GHC 8.4.1. These include: A regression resulting in some uses of Control.Exception.evaluate to be inappropriately optimised away (see #13930) A regression resulting in segmentation faults of programs compiled with profiling (#14705) A bug causing runtime system panics while running programs with retainer profiling (#14947) The configure scripts now accepts a --disable-dtrace option, again allowing GHC to be bootstrapped on FreeBSD (#15040) The version number of the base package has been bumped to 4.11.1.0 to reflect the addition of the GHC.IO.FixIOException type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, ​https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_4_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at ​https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release ... [More] , fixing numerous regressions and bugs present in GHC 8.4.1. These include: A regression resulting in some uses of Control.Exception.evaluate to be inappropriately optimised away (see #13930) A regression resulting in segmentation faults of programs compiled with profiling (#14705) A bug causing runtime system panics while running programs with retainer profiling (#14947) The configure scripts now accepts a --disable-dtrace option, again allowing GHC to be bootstrapped on FreeBSD (#15040) The version number of the base package has been bumped to 4.11.1.0 to reflect the addition of the GHC.IO.FixIOException type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, ​https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_4_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at ​https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As ... [More] such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, Further refinement of TypeInType, including significant improvements in error messages. Improvements in code generation resulting in noticable performance improvements in some types of programs. Core library improvements, including phase 2 of the Semigroup/Monoid proposal Many improvements to instance deriving The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, ​https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html There are a few changes in release-engineering matters that should be noted, This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_4_1.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. ... [More] Notable bug-fixes include A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) A correctness issue resulting in undefined behavior in some programs using STM (#14171) A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) clearBit of Natural no longer bottoms (#13203) A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) GHC again supports production of position-independent executables (#13702) Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, ​https://haskell.org/ghc/docs/8.2.2/html/users_guide/8.2.2-notes.html How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. ... [More] Notable bug-fixes include A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) A correctness issue resulting in undefined behavior in some programs using STM (#14171) A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) clearBit of Natural no longer bottoms (#13203) A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) GHC again supports production of position-independent executables (#13702) Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, ​https://haskell.org/ghc/docs/8.2.2/html/users_guide/8.2.2-notes.html How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. ... [More] Notable bug-fixes include A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) A correctness issue resulting in undefined behavior in some programs using STM (#14171) A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) clearBit of Natural no longer bottoms (#13203) A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) GHC again supports production of position-independent executables (#13702) Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, ​https://haskell.org/ghc/docs/8.2.2/html/users_guide/8.2.2-notes.html How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. ... [More] Notable bug-fixes include A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) A correctness issue resulting in undefined behavior in some programs using STM (#14171) A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) clearBit of Natural no longer bottoms (#13203) A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) GHC again supports production of position-independent executables (#13702) Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, ​https://haskell.org/ghc/docs/8.2.2/html/users_guide/8.2.2-notes.html How to get it This release can be downloaded from ​https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see ​https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources Relevant URLs on the World-Wide Web: ​GHC home page ​GHC developers' home page ​Haskell home page Supported Platforms The list of platforms we support, and the people responsible for them, is ​here Ports to other platforms are possible with varying degrees of difficulty. The ​Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by ​Trac. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

While Phabricator is generally well-liked among GHC developers, GHC's interaction with Harbormaster, Phabricator's continuous integration component, has been less than rosy. The problem is in large part a mismatch between Harbormaster's design ... [More] assumptions and GHC's needs, but it's also in part attributable to the somewhat half-finished state in which Harbormaster seems to linger. Regardless, we won't go into detail here; these issues are well covered elsewhere. Suffice it to say that, after having looked at a number of alternatives to Harbormaster (including ​buildbot, GitLab's ​Pipelines, ​Concourse, and home-grown solutions), Jenkins seems to be the best option at the moment. Of course, this is not to say that it is perfect; as we have learned over the last few months it is very far from perfect. However, it has the maturity and user-base to be almost-certainly able to handle what we need of it on the platforms that we care about. See the Trac ticket #13716 Let's see what we get out of this new bit of infrastructure: Pre-merge testing Currently there are two ways that code ends up in master, a Differential is opened, built with Harbormaster, and eventually landed (hopefully, but not always, after Harbormaster successfully finishes) someone pushes commits directly Bad commits routinely end up merged via both channels. This means that authors of patches failing CI often need to consider whether *their* patch is incorrect or whether they rather simply had the misfortune of basing their patch on a bad commit. Even worse, if the commit isn't quickly reverted or fixed GHC will end up with a hole in its commit history where neither bisection nor performance tracking will be possible. For these reasons, we want to catch these commits before they make it into master. To accomplish this we have developed some ​tooling to run CI on commits *before* they are finally merged to master. By making CI the only path patches can take to get to master, improve our changes of rejecting bad patches before they turn the tree red. Automation of the release builds Since the 7.10.3 release we have been gradually working towards automating GHC's release process. Thanks to this work, today a single person can build binary distributions for all seven tier-1 configurations in approximately a day, most of which is spent simply waiting. This has allowed us to take responsibility (starting in 8.2.1) for the OpenBSD, FreeBSD, ARMv7 and AArch64 builds in addition to the traditional tier-1 platforms, allowing us to eliminate the week-long wait between source distribution availability and the binary distribution announcement previously needed for correspondence with binary build contributors.. However, we are far from done: our new Jenkins-based build infrastructure (see #13716) will allow us to produce binary distributions directly from CI, reducing the cost of producing release builds to nearly nothing. Testing of GHC against user packages While GHC is already tested against Hackage and Stackage prior to release candidate availability, these builds have been of limited use as packages low on the dependency tree (think hashable and lens) often don't build prior to the first release candidate. While we do our best to fix these packages up, the sheer number of them makes this a losing battle for a small team such as GHC's. Having the ability to cheaply produce binary distributions means that we can produce and validate nightly snapshot releases. This gives users a convenient way to test pre-release compilers and fix their libraries accordingly. We hope this will spread the maintenance effort across a larger fraction of the Haskell community and over a longer period of time, meaning there will be less to do at release time and consequently pre-release Stackage builds will be more fruitful. Once the Jenkins infrastructure is stable, we can consider introducing nightly builds of user packages as well. While building a large population such as Stackage would likely not be productive, working with a smaller sample of popular, low-dependency-count packages would be quite possible. For testing against larger package repositories, leaning on a dedicated tool such as the ​Hackage Matrix Builder will likely be a more productive path. Expanded platform coverage of CI While GHC targets a wide variety of architectures and operating systems (and don't forget cross-compilation targets), by far the majority of developers use Linux, Darwin, or Windows on amd64. This means that breakage often only comes to light long after the culpable patch was merged. Of course, GHC, being a project with modest financial resources, can't test each commit on every supported platform. We can, however, shrink the time between a bad commit being merged and the breakage being found by testing these "unusual" platforms on a regular (e.g. nightly) basis. By catching regressions early, we hope to reduce the amount of time spent bisecting and fixing bugs around release time. Tracking core libraries Keeping GHC's core library dependencies (e.g. directory, process) up-to-date with their respective upstreams is important to ensure that tools that link against the ghc library (e.g. ghc-mod) can build easily. However, it also requires that we work with nearly a dozen upstream maintainers at various points in their own release cycles to arrange that releases are made prior to the GHC release. Moreover, there is inevitably a fair amount of work propagating verion bounds changes down the dependency tree. While this work takes relatively little effort in terms of man-hours, Jenkins can help us here by allowing us to automate integration testing of upstream libraries, catching bounds issues and other compatibility issues well before they are in the critical path of the release. Improved debugging tools One of the most useful ways to track down a bugs in GHC is bisection. This is especially true for regressions found in release candidates, where you have at most a few thousand commits to bisect through. Nevertheless, GHC builds are long and developer time scarce so this approach isn't used as often as it could be. Having an archive of nightly GHC builds will free the developer from having to build dozens of compilers during bisection, making the process a significantly more enjoyable experience than it is today. This will allow us to solve more bugs in less time and with far fewer grey hairs. Status of Jenkins effort The Jenkins CI overhaul has been an on-going project throughout the spring and summer and is nearing completion. The Jenkins configuration can be seen in the wip/jenkins branch on git.haskell.org (​gitweb). At the moment the prototype is running on a few private machines but we will be setting up a publicly accessible test instance in the coming weeks. Jenkins will likely coexist with our current Harbormaster infrastructure for a month or so while we validate that things are stable. [Less]

While Phabricator is generally well-liked among GHC developers, GHC's interaction with Harbormaster, Phabricator's continuous integration component, has been less than rosy. The problem is in large part a mismatch between Harbormaster's design ... [More] assumptions and GHC's needs, but it's also in part attributable to the somewhat half-finished state in which Harbormaster seems to linger. Regardless, we won't go into detail here; these issues are well covered elsewhere. Suffice it to say that, after having looked at a number of alternatives to Harbormaster (including ​buildbot, GitLab's ​Pipelines, ​Concourse, and home-grown solutions), Jenkins seems to be the best option at the moment. Of course, this is not to say that it is perfect; as we have learned over the last few months it is very far from perfect. However, it has the maturity and user-base to be almost-certainly able to handle what we need of it on the platforms that we care about. See the Trac ticket #13716 Let's see what we get out of this new bit of infrastructure: Pre-merge testing Currently there are two ways that code ends up in master, a Differential is opened, built with Harbormaster, and eventually landed (hopefully, but not always, after Harbormaster successfully finishes) someone pushes commits directly Bad commits routinely end up merged via both channels. This means that authors of patches failing CI often need to consider whether *their* patch is incorrect or whether they rather simply had the misfortune of basing their patch on a bad commit. Even worse, if the commit isn't quickly reverted or fixed GHC will end up with a hole in its commit history where neither bisection nor performance tracking will be possible. For these reasons, we want to catch these commits before they make it into master. To accomplish this we have developed some ​tooling to run CI on commits *before* they are finally merged to master. By making CI the only path patches can take to get to master, improve our changes of rejecting bad patches before they turn the tree red. Automation of the release builds Since the 7.10.3 release we have been gradually working towards automating GHC's release process. Thanks to this work, today a single person can build binary distributions for all seven tier-1 configurations in approximately a day, most of which is spent simply waiting. This has allowed us to take responsibility (starting in 8.2.1) for the OpenBSD, FreeBSD, ARMv7 and AArch64 builds in addition to the traditional tier-1 platforms, allowing us to eliminate the week-long wait between source distribution availability and the binary distribution announcement previously needed for correspondence with binary build contributors.. However, we are far from done: our new Jenkins-based build infrastructure (see #13716) will allow us to produce binary distributions directly from CI, reducing the cost of producing release builds to nearly nothing. Testing of GHC against user packages While GHC is already tested against Hackage and Stackage prior to release candidate availability, these builds have been of limited use as packages low on the dependency tree (think hashable and lens) often don't build prior to the first release candidate. While we do our best to fix these packages up, the sheer number of them makes this a losing battle for a small team such as GHC's. Having the ability to cheaply produce binary distributions means that we can produce and validate nightly snapshot releases. This gives users a convenient way to test pre-release compilers and fix their libraries accordingly. We hope this will spread the maintenance effort across a larger fraction of the Haskell community and over a longer period of time, meaning there will be less to do at release time and consequently pre-release Stackage builds will be more fruitful. Once the Jenkins infrastructure is stable, we can consider introducing nightly builds of user packages as well. While building a large population such as Stackage would likely not be productive, working with a smaller sample of popular, low-dependency-count packages would be quite possible. For testing against larger package repositories, leaning on a dedicated tool such as the ​Hackage Matrix Builder will likely be a more productive path. Expanded platform coverage of CI While GHC targets a wide variety of architectures and operating systems (and don't forget cross-compilation targets), by far the majority of developers use Linux, Darwin, or Windows on amd64. This means that breakage often only comes to light long after the culpable patch was merged. Of course, GHC, being a project with modest financial resources, can't test each commit on every supported platform. We can, however, shrink the time between a bad commit being merged and the breakage being found by testing these "unusual" platforms on a regular (e.g. nightly) basis. By catching regressions early, we hope to reduce the amount of time spent bisecting and fixing bugs around release time. Tracking core libraries Keeping GHC's core library dependencies (e.g. directory, process) up-to-date with their respective upstreams is important to ensure that tools that link against the ghc library (e.g. ghc-mod) can build easily. However, it also requires that we work with nearly a dozen upstream maintainers at various points in their own release cycles to arrange that releases are made prior to the GHC release. Moreover, there is inevitably a fair amount of work propagating verion bounds changes down the dependency tree. While this work takes relatively little effort in terms of man-hours, Jenkins can help us here by allowing us to automate integration testing of upstream libraries, catching bounds issues and other compatibility issues well before they are in the critical path of the release. Improved debugging tools One of the most useful ways to track down a bugs in GHC is bisection. This is especially true for regressions found in release candidates, where you have at most a few thousand commits to bisect through. Nevertheless, GHC builds are long and developer time scarce so this approach isn't used as often as it could be. Having an archive of nightly GHC builds will free the developer from having to build dozens of compilers during bisection, making the process a significantly more enjoyable experience than it is today. This will allow us to solve more bugs in less time and with far fewer grey hairs. Status of Jenkins effort The Jenkins CI overhaul has been an on-going project throughout the spring and summer and is nearing completion. The Jenkins configuration can be seen in the wip/jenkins branch on git.haskell.org (​gitweb). At the moment the prototype is running on a few private machines but we will be setting up a publicly accessible test instance in the coming weeks. Jenkins will likely coexist with our current Harbormaster infrastructure for a month or so while we validate that things are stable. [Less]