` directive is now supported. This allows common configuration to be shared across multiple files. For example, a project that maintains multiple project-level configuration files for testing against different snapshots can use `!include` to avoid duplicating shared settings.
- Stack’s `config set` command raises an error if the target configuration file excludes the key being set and includes an `!include` directive.
- Stack’s `config set snapshot` command now works with other snapshot values in addition to snapshot synonymns.
- Add Stack’s `config compiler-tools` command to create (when applicable) the compiler tools directory for the specified compiler version (implies Stack’s `config build-files` command).
Bug fixes:
- Stack’s `dot` and `ls dependencies` commands no longer prune a package with dependencies only because all its direct dependencies are to be pruned.
- After March 2026, Hackage requires Stack’s user agent to be set when applying digest authentication to a request. Stack’s `upload` command now does that, re-establishing authentication by Hackage username and password.
- Stack 3.9.3 and earlier fail to construct a build plan if project package A depends on project package B and package B’s executables (only) depend on package A and the name of A is before that of B, alphabetically. That bug is fixed.
- Stack’s `config set` commands will recreate the `global-project` directory contents, if Stack needs to consult its project-level configuration file and there is no file.
- The output of Stack’s `path --bin-path` command is now consistent with the Stack environment in Stack’s `exec` command and includes the `bin` directory of Stack’s local install root directory.
- Stack now builds packages that depend directly on packages with the same name as a sublibrary or foreign library of the package.
- On Windows, Stack’s `build` command now accepts a build directory that is a long path.
**Thanks to all our contributors for this release:**
- Bryan Richter
- Ching Pei Yang
- Dan Burton
- David Vollbracht
- Mike Pilgrem
- Olivier Benz
---
### Author:  [@benz0li](https://discourse.haskell.org/u/benz0li)
#### Post date: [June 15, 2026, 3:24am UTC](https://discourse.haskell.org/t/ann-stack-3-11-1/14272/2 "2026-06-15T03:24:24Z")
_Unofficial_ Linux/RISC-V (64-bit, `linux/riscv64` ) release assets are available at [v3.11.1 · Commercial Haskell / stack · GitLab](https://gitlab.b-data.ch/commercialhaskell/stack/-/releases/v3.11.1).
* * *
Due to ongoing DDoS attacks, access to b-data’s IT infrastructure has been blocked for all Chinese servers.
ℹ For any requests to unblock individual Chinese IPs or CIDR blocks, please contact [olivier.benz@b-data.ch](mailto:olivier.benz@b-data.ch).
---
### Author:  [@benz0li](https://discourse.haskell.org/u/benz0li)
#### Post date: [June 18, 2026, 7:27pm UTC](https://discourse.haskell.org/t/ann-stack-3-11-1/14272/3 "2026-06-18T19:27:28Z")
The _[GHC musl](https://github.com/benz0li/ghc-musl)_ docker manifests (`linux/amd64`, `linux/arm64/v8`) for GHC versions 9.14.1, 9.12.4, 9.10.3, 9.8.4 and 9.6.7 now include Stack version 3.11.1. Available from
[Quay](https://quay.io/repository/benz0li/ghc-musl):
- `quay.io/benz0li/ghc-musl:9.14.1`
- `quay.io/benz0li/ghc-musl:9.14.1-int-native`
- `quay.io/benz0li/ghc-musl:9.12.4`
- `quay.io/benz0li/ghc-musl:9.12.4-int-native`
- `quay.io/benz0li/ghc-musl:9.10.3`
- `quay.io/benz0li/ghc-musl:9.10.3-int-native`
- `quay.io/benz0li/ghc-musl:9.8.4`
- `quay.io/benz0li/ghc-musl:9.8.4-int-native`
- `quay.io/benz0li/ghc-musl:9.6.7`
- `quay.io/benz0li/ghc-musl:9.6.7-int-native`
[Docker Hub](https://hub.docker.com/r/benz0li/ghc-musl):
- `docker.io/benz0li/ghc-musl:9.14.1`
- `docker.io/benz0li/ghc-musl:9.14.1-int-native`
- `docker.io/benz0li/ghc-musl:9.12.4`
- `docker.io/benz0li/ghc-musl:9.12.4-int-native`
- `docker.io/benz0li/ghc-musl:9.10.3`
- `docker.io/benz0li/ghc-musl:9.10.3-int-native`
- `docker.io/benz0li/ghc-musl:9.8.4`
- `docker.io/benz0li/ghc-musl:9.8.4-int-native`
- `docker.io/benz0li/ghc-musl:9.6.7`
- `docker.io/benz0li/ghc-musl:9.6.7-int-native`
The manifests for GHC versions 9.14.1, 9.12.4 and 9.10.3 also include an image for `linux/riscv64`.
ℹ Please be aware that these are _unofficial_ and _untested_ binary distributions of GHC on Alpine Linux.
---
### Author:  [@janus](https://discourse.haskell.org/u/janus)
#### Post date: [June 19, 2026, 3:58pm UTC](https://discourse.haskell.org/t/ann-stack-3-11-1/14272/4 "2026-06-19T15:58:46Z")
I want to make sure I am using [the v2 semaphore protocol](http://well-typed.com/blog/2026/06/haskell-ecosystem-report-march-may-2026/#semaphores-and--jsem) with GHC 10.0 when it is released. I see that [Stack uses the semaphore-compat library](https://github.com/commercialhaskell/stack/pull/6851/changes#diff-e0ee4e21f8811c1171864cc68ea4005347b1b0ca70626026f251bf4111c2aa6e).
I would like to ensure that I am using the v2 library exclusively.
How can I determine which versions of libraries (like e.g. semaphore-compat) my stack build has been linked against?
---
### Author:  [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)
#### Post date: [June 20, 2026, 5:05pm UTC](https://discourse.haskell.org/t/ann-stack-3-11-1/14272/5 "2026-06-20T17:05:16Z")
The ‘official’ build of Stack 3.11.1 is built against GHC 9.10.3 and the GHC boot package is `semaphore-compat-1.0.0`.
The changes to Stack’s code in respect of Semaphore are principally at:
- [Add --semaphore by horriblename · Pull Request #6851 · commercialhaskell/stack · GitHub](https://github.com/commercialhaskell/stack/pull/6851)
More generally, `stack --version` (in an ‘official’ build) will output a Git commit hash and that can be used to identify the contents of `stack.yaml` at that point in the commit history (that being the file that specifies the GHC version and the set of package versions).