Release 2.9.0.1

[wz1000]

This is a bindist only release.

Release checklist

• check ghcup supports new GHC releases if any
• set the supported GHCs in workflow file .github/workflows/release.yaml
  • There is currently a list of GHC versions for each major platform. Search for ghc: [ to find all lists.
  • Look for TODO: to find locations that require extra care for GHC versions.
• check all plugins still work if release includes code changes
• bump package versions in all *.cabal files (same version as hls)
  • HLS uses lockstep versioning. The core packages and all plugins use the same version number, and only support exactly this version.
    • Exceptions:
      • hie-compat requires no automatic version bump.
      • shake-bench is an internal testing tool, not exposed to the outside world. Thus, no version bump required for releases.
  • For updating cabal files, the following script can be used:

    • ./release/update_versions.sh <OLD_VERSION> <NEW_VERSION>

    • It still requires manual verification and review
• generate and update changelog
  • Generate a ChangeLog via ./GenChangelogs.hs <api-key> <tag>
    • <tag> is the git tag you want to generate the ChangeLog from.
    • <api-key> is a github access key: https://github.com/settings/tokens
• update https://haskell-language-server.readthedocs.io/en/latest/support/ghc-version-support.html#current-ghc-version-support-status
• create release branch as wip/<version>
  • git switch -c wip/<version>
• create release tag as <version>
  • git tag <version>
• trigger release pipeline by pushing the tag
  • this creates a draft release
  • git push <remote> <version>
• run sh scripts/release/download-gh-artifacts.sh <version> <your-gpg-email>
  • downloads artifacts to gh-release-artifacts/haskell-language-server-<version>/
  • also downloads FreeBSD bindist from circle CI
  • adds signatures
• upload artifacts to downloads.haskell.org from gh-release-artifacts/haskell-language-server-<version>/
  • You require sftp access, contact wz1000, bgamari or chreekat
  • cd gh-release-artifacts/haskell-language-server-<version>
  • SIGNING_KEY=... ../../release/upload.sh upload
    • Your SIGNING_KEY can be obtained with gpg --list-secret-keys --keyid-format=long
  • Afterwards, the artifacts are available at: https://downloads.haskell.org/~hls/haskell-language-server-<version>/
  • Run SIGNING_KEY=... ../../release/upload.sh purge_all to remove CDN caches
• create PR to ghcup-metadata
  • update ghcup-vanilla-0.0.8.yaml and ghcup-vanilla-0.0.7.yaml
    • can use sh scripts/release/create-yaml-snippet.sh <version> to generate a snippet that can be manually inserted into the yaml files
  • update hls-metadata-0.0.1.json Currently unnecessary, GHCup builds its own HLS binaries and updates that file.
    • utilize cabal run ghcup-gen -- generate-hls-ghcs -f ghcup-0.0.7.yaml --format json --stdout in the root of ghcup-metadata repository
  • Be sure to mark the correct latest version and add the 'recommended' tag to the latest release.
• get sign-off on release
  • from wz1000, michealpj, maerwald and fendor
• publish release on github
• upload hackage packages
  • requires credentials
• Supported tools table needs to be updated:
  • https://www.haskell.org/ghcup/install/#supported-platforms
  • https://github.com/haskell/ghcup-hs/blob/master/docs/install.md#supported-platforms
  • https://github.com/haskell/ghcup-metadata/blob/44c6e2b5d0fcae15abeffff03e87544edf76dd7a/ghcup-gen/Main.hs#L67
• post release on discourse and reddit
• merge release PR to master or forward port relevant changes

[jhrcek]

I'm not sure why the diff renders as such, but I'm applying changes on top of the 2.9.0.0 tag.

I guess you should have opened the PR targetting commit with https://github.com/haskell/haskell-language-server/tree/2.9.0.0 tag, not master. Then you wouldn't see this diff / wouldn't have merge conflicts?

[wz1000]

I will rebase the PR over master once the release jobs succeed.

[hasufell]

I will rebase the PR over master once the release jobs succeed.

This is confusing. The release branch now contains code changes compared to wip/2.9.0.0. What is the reasoning for this?

[hasufell]

I will rebase the PR over master once the release jobs succeed.

This is almost certainly wrong.

You have to forward port the CI changes in the release branch to master, not merge master back into the release branch.

[wz1000]

The 2.9.0.1 tag exists. I'm not sure what having the wip/2.9.0.0 branch will add to this.

[hasufell]

The 2.9.0.1 tag exists. I'm not sure what having the wip/2.9.0.0 branch will add to this.

You're breaking expectations of how basically everyone else uses release branches. You never merge back master into release branches.

Other people may be using your release branches, e.g. for distribution purposes. How are they supposed to know that only the tag has correct semantics? Tags are not branches.

[wz1000]

For the purposes of HLS as of now, the release branches are basically just staging areas, as indicated by the wip in the name. If you want a handle on a stable commit, use the tag after the release is published.

[wz1000]

This has been true for a while, for example on the wip/2.9.0.0 branch: https://github.com/haskell/haskell-language-server/commits/wip/2.9.0.0/

[michaelpj]

I would not expect wip/<version> to be a release branch, and indeed we don't have release branches.