Release 1.7.0

[pepeiborra]

The main change in this release will be the switch to dynamically linked binaries for distribution, contributed by @hasufell

As usual we need a volunteer to drive the release.

Release blockers

• VSCode extension upgraded to use ghcup for installation

Prerelease steps

• trigger manually the hackage workflow without uploading the packages
• trigger manually the build workflow
• create a prerelease tag 1.7.0-check-gitlab and push it to the project repo in gitlab to check the build is fine

Github release steps

• generate the list of pull requests finished since the last release using the haskell script in the project root.
  Nix users should run command gen-hls-changelogs (a wrapper of the script) in nix-shell instead.
• add that list to the actual Changelog with a description of the release.
• bump up versions of changed packages. All are optional but haskell-language-server itself.
• create the tag and make an initial prerelease to trigger the ci workflow (see details below)
• contact ghcup team (#haskell-ghcup irc channel or via its repo) to try to sync our release and its inclusion in ghcup
• in the github release edit page, check the attached binaries and the release description (usually the changelog entry) and uncheck the prerelease box
• make public the release in the usual social channels (not required but useful to spread the word 🙂):
  • irc
  • matrix
  • twitter
  • discord
  • discourse
  • reddit
  • [ ]

hackage release

• bump up package versions following the pvp specification if they are not already updated. You must use policeman (build from HEAD) to help with this step.
• create 1.7.0-hackage branch to trigger the hackage github workflow which will upload all changed packages to hackage as candidates
• check manually candidates in hackage
• publish them definitely

ghcup release

• push the release tag to the haskell-language-server gitlab repo to trigger the build of ghcup specific artifacts
• download specific artifacts only available in the gitlab build and compute their sha256sum
• upload them to the github release and complete the SHA256SUMS file
• change ghcup metadata to include the new release in https://github.com/haskell/ghcup-metadata
  • example pull request here

[hasufell]

I'm preparing a ghcup release.

[hasufell]

Released.

[hasufell]

This should also be merged before release #2738

Who is maintaning the vscode extension?

[fendor]

Who is maintaning the vscode extension?

@jneira takes care of releases, iirc

[jneira]

Doing the release is matter of push a tag, create a github release and make it definitive (see https://github.com/haskell/vscode-haskell/blob/master/.github/workflows/build.yml).
Feel free to ask any question about when doing it.
Many of hls maintainers are also maintainers of the vscode extension and can do merges, reviews and releases but let me know if anyone needs some type of permission to do the required changes.

[hasufell]

The question is how does vscode extension install HLS?

[jneira]

Here is the main entry point: https://github.com/haskell/vscode-haskell/blob/79456aaaa98b98f9e7b9f690bb18ab2b2838b6e2/src/extension.ts#L194

[hasufell]

It appears not: https://github.com/haskell/vscode-haskell/blob/79456aaaa98b98f9e7b9f690bb18ab2b2838b6e2/src/hlsBinaries.ts#L317

[pepeiborra]

One issue with using ghcup to install HLS is specifying the target GHC version, which can be custom to the cradle and different from the one set in ghcup or the one in the PATH. Currently the VSCode extension uses the hls-wrapper to find out the project GHC version.

If not using ghcup, we would need to teach the VSCode extension to use the make script included in the new HLS binary distribution

[hasufell]

One issue with using ghcup to install HLS is specifying the target GHC version, which can be custom to the cradle and different from the one set in ghcup or the one in the PATH. Currently the VSCode extension uses the hls-wrapper to find out the project GHC version.

If not using ghcup, we would need to teach the VSCode extension to use the make script included in the new HLS binary distribution

What's the exact issue? ghcup just installs all of them.

[pepeiborra]

Validation: ghcup doesn't know what the project ghc is so it cannot validate whether HLS binaries exist.

[hasufell]

Validation: ghcup doesn't know what the project ghc is so it cannot validate whether HLS binaries exist.

Why would ghcup need to know that? The VSCode extension knows and can easily check whether a haskell-language-server-<ghcver> binary exists.