New release

[NorfairKing]

Hi @mpilgrem.
Any chance we could cut a release before the new nixos release is cut this month?

[mpilgrem]

I do not know what triggers a new stack release - I am more janitor than architect. Looking at past releases, perhaps @borsboom (linked to past releases) can advise. It would be good if a new release could take into account #5697 (move to GHC 9.0.2) and #5732 (upgrade MYSY2). Perhaps it is important also first to understand better #5721 (stack making much larger executables than before).

[NorfairKing]

Hey Manny, long time no see!
@borsboom Could we get a release and/or a look at these issues?

[hasufell]

There's a plethora of unattended PRs from contributors, e.g.:

• Pass 'with-gcc:' specified compiler to 'stack setup', fixes #5493 #5609
• Fix how cpp-options are passed to ghci wrt #5532 #5608
• Use capi calling convention for ioctl #5699
• Avoid doing slow IO twice when running stack path #5645
• etc.

[nh2]

There's a plethora of unattended PRs from contributors, e.g.:

I have reviewed those 4, they all look good to me.

Also as per linked issue freebsd/freebsd-ports-haskell#62 above, a new release might also help FreeBSD.

[NorfairKing]

@nh2 Excellent! Could you ping Manny ? :D

[arrowd]

Any movement on this?

[hasufell]

From my side I think #5609 should be merged and then there should be a release in the near future, so that ghcup can make use of the new GHC installation hooks and pre-install stack by default.

[mpilgrem]

#5609 is now merged. Personally, I would like to move Stack to GHC 9.0.2 (current LTS) or GHC 9.2.3 (currently nightly)/GHC9.2.4 (released 28 July 2022, resolver=ghc-9.2.4 now available). @psibi considers that haskell/process#251 is not a block in that regard, but I would be happier if the integration tests passed on macOS. I also think it would be 'neater' to have an extra-dep that is not tied to a particular commit of process to cover the resolution of haskell/process#250 (but to a yet-to-come version of process released on Hackage).

[psibi]

@psibi considers that haskell/process#251 is not a block in that regard, but I would be happier if the integration tests passed on macOS.

Yeah, the integration test passes with the workaround we have for MacOS. But it seems it's currently failing now, but I'm hoping that it should be easy to get it resolved.

I also think it would be 'neater' to have an extra-dep that is not tied to a particular commit of process to cover the resolution of haskell/process#250 (but to a yet-to-come version of process released on Hackage).

Agree, but I think it's okay. :-) But there is one more issue that needs to get resolved in the process package: haskell/process#251 - We would need to remove the workaround we have Stack in now once that get's resolved. But I don't think we should hold release of stack for it.

[mpilgrem]

The fix for haskell/process#250 is now on Hackage, and I hope I've put that through #5763 (waiting on the CI).

[mpilgrem]

I am flagging this discussion to @snoyberg and @borsboom, in case they are willing and able to assist with a new release of Stack.

Thanks to @psibi, Stack has now been moved to GHC 9.2.4. There may be others better placed to release a new version of Stack binaries than me, but I am willing to work through the steps at https://github.com/commercialhaskell/stack/blob/master/doc/maintainers/releases.md. However, I would need some help/guidance for certain steps, as identified below (I am a Windows 11 user, with access to Windows Subsystem for Linux 2. My practical experience of Linux is limited, largely to CI scripts on GitHub).

I understand that all of the steps from https://github.com/commercialhaskell/stack/blob/master/doc/maintainers/releases.md#build-linux-static-binary-distribution-with-nix are no longer relevant, given the GitHub workflows in integration-tests.yml and arm64-release.yml.

[1] What is 'your GPG key', how do you get a GPG key, and how do you sign your key so that it is 'authorised'?

I have no knowledge or experience of GPG (GNU Privacy Guard).

This relates to step:

Push signed Git tag. For final releases the tag should be vX.Y.Z (where X.Y.Z matches the version in package.yaml from the previous step); for release candidates it should be rc/vX.Y.Z.A. e.g.: git tag -u <YOUR-GPG-KEY> -m vX.Y.Z vX.Y.Z && git push origin vX.Y.Z. [RC]

I have also read:

• https://git-scm.com/book/en/v2/Git-Basics-Tagging on annotated Git tagging
• https://git-scm.com/docs/git-tag on the git tag command
• https://github.com/commercialhaskell/stack/blob/master/doc/SIGNING_KEY.md which refers to signing a key to 'authorise' it
• keyserver of signing key seems unavailable #5693, which identifies that https://sks-keyservers.net/ is a dead link in Stack's documentation
• parts of https://gnupg.org/, but it is a large site and I find it difficult to distinguish what is relevant to the step from what is irrelevant

[2] How do you 'activate versions' on https://readthedocs.org/projects/stack/versions/?

I think @borsboom may be the only Maintainer of that Read the Docs account (see https://readthedocs.org/projects/stack/).

This relates to step:

Activate version for new release tag, on readthedocs.org

[3] How do you update the '/stable and /upgrade rewrite rules' at https://raw.githubusercontent.com/commercialhaskell/stack/stable/etc/scripts/get-stack.sh?

This relates to step:

Update get.haskellstack.org /stable and /upgrade rewrite rules with the new version

The URL in the step above is dud, for me. https://get.haskellstack.org redirects to https://raw.githubusercontent.com/commercialhaskell/stack/stable/etc/scripts/get-stack.sh. I do not know to what part of the script reference is being made.

[4] What is 'ArgoCD', and how do you 'sync an application' in it?

This relates to step:

sync the application in ArgoCD

The URL in the step above is dud, for me.

It is not obvious to me what this step is intended to do or if it is still required.

I have read:

• https://argo-cd.readthedocs.io/en/stable/ "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes." but I have no experience of Kubernetes, Git Ops, or continuous delivery tools.

[5] Are all of the mailing lists haskell-cafe@haskell.org, haskell-stack@googlegroups.com, and commercialhaskell@googlegroups.com still valid, or have any of them been overtaken/replaced by the Haskell Community?

This relates to step:

Announce to haskell-cafe@haskell.org; haskell-stack@googlegroups.com; commercialhaskell@googlegroups.com mailing lists, subject ANN: stack-X.Y.Z (or ANN: first release candidate for stack-X.Y.x), containing the release description from Github. [RC]

[6] What is a Docker image, can you create a relevant one on Windows and, if so, how?

I have very limited knowledge and no practical experience of Docker. @psibi somehow solved the Docker-related aspects of moving Stack to GHC 9.2.4.

This relates to step:

Update fpco/stack-build Docker images with new version

• Under commercialhaskell/stackage/automated/dockerfiles, add lts-X.Y/Dockerfile (where X.Y is the latest stackage LTS version), containing (note where X.Z is the previous LTS version, and X.Y.Z is the newly released stack version)

   FROM $DOCKER_REPO:lts-X.Z
   ARG STACK_VERSION=X.Y.Z
   RUN wget -qO- https://github.com/commercialhaskell/stack/releases/download/v$STACK_VERSION/stack-$STACK_VERSION-linux-x86_64.tar.gz | tar xz --wildcards --strip-components=1 -C /usr/local/bin '*/stack'
  

• Run ./build.sh lts-X.Y and test that the new image has the new version of Stack (e.g. docker run --rm fpco/stack-build:lts stack --version).

• Run ./build.sh --push lts-X.Y && ./build.sh --push --small lts-X.Y to push the new image to the registry.

I have also read:

• The introduction to https://github.com/commercialhaskell/stack/blob/master/doc/docker_integration.md which states 'Windows does not work at all'.
• https://docs.docker.com/get-started/, which indicates that a product 'Docker Desktop' does exist for Windows.

[7] What is required to include builds for ARM64/AArch64 in the release?

This relates to this issue: #5709, which calls for ARM64/AArch64 binary versions of Stack.

I understand:

• ARM64 and AArch64 refer to the same thing
• The GitHub workflow arm64-release builds binary distributions and uploads them as artifacts, and it currently passes.