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.

[pepeiborra]

I thought that we wanted to make the VSCode extension dumb and delegate all the work on GHCup.

[hasufell]

I thought that we wanted to make the VSCode extension dumb and delegate all the work on GHCup.

I don't see how that would work. GHCup isn't going to add functionality specific to a VSCode extension. It can install HLS into an isolated dir easily without affecting the global installation.

So something along these lines:

1. make ghcup available
   • if it already exists in releasesDownloadStoragePath, run <ghcup-binary> upgrade --inplace
   • if it doesn't exist, download it from https://downloads.haskell.org/~ghcup/<arch>-<platform>-ghcup
2. check if HLS is in <releasesDownloadStoragePath>/bin
   • if it already exists and is the most recent version, do nothing
   • if it exists, but is outdated remove <releasesDownloadStoragePath>/bin and <releasesDownloadStoragePath>/lib, then run <ghcup-binary> install hls --isolate <releasesDownloadStoragePath> --force <hls-ver>
   • if it doesn't exist, run <ghcup-binary> install hls --isolate <releasesDownloadStoragePath> --force <hls-ver>
3. Check if <releasesDownloadStoragePath>/bin/haskell-language-server-<project-ghcver> exists
   • if yes, succeed and add <releasesDownloadStoragePath>/bin to PATH
   • if not, abort and tell the user to compile HLS from source

So, is anyone going to work on the VSCode extension? I'm not a VSCode user and not familiar with the code.

[hasufell]

haskell/vscode-haskell#533

[fendor]

@wz1000 reported some bug with the new hie-bios version. No details yet

[hasufell]

Another release blocker: #2746

[hasufell]

@wz1000 reported some bug with the new hie-bios version. No details yet

Do we have details now?

[fendor]

Opened an issue: haskell/hie-bios#336

[wz1000]

I can do the HLS release this time, but I will need hackage permissions for the many packages.

[Abastro]

Is the hie-bios update included here? I am having problem with HLS not recognizing "with-compiler" option.

[pepeiborra]

I can do the HLS release this time, but I will need hackage permissions for the many packages.

Thank you !!! I will create an hls_team umbrella Hackage account and share auth details via IRC

[fendor]

@Abastro What hie-bios update? This release comes with hie-bios 0.9.0, the latest hackage release and without new patches.

Can you specify our issue?

[Abastro]

@Abastro What hie-bios update? This release comes with hie-bios 0.9.0, the latest hackage release and without new patches.

Can you specify our issue?

Yes, hie-bios 0.9.0 comes with a fix to conform to cabal's "with-compiler".
I am looking forward to new hls release coming with hie-bios 0.9.0, it seems like I cannot install the 0.9.0 version along with currently available hls.

[fendor]

@Abastro Why not? I installed it from source, and it worked out of the box. Or do you mean you tried installing hie-bios alongside HLS? You'll have to build HLS from source, too.

[Abastro]

@fendor I tried building from source through ghcup, with constraint on hie-bios == 0.9.0 and allow-newer. Did not work for me :<

[fendor]

Installation failed, the feature did not work or HLS crashed?

[Abastro]

Did not install. Cabal does not even try hie-bios 0.9.0., even with allow-newer.

[hasufell]

@fendor I tried building from source through ghcup, with constraint on hie-bios == 0.9.0 and allow-newer. Did not work for me :<

Try --cabal-project-local https://gist.githubusercontent.com/hasufell/8409effe97d33c36369e4d9906556c1e/raw/0d6caaabaa974430c2c3b3ba68a4872d2a984dbf/gistfile1.txt

[Abastro]

Yep, also fails - with following ghcup log's cabal part.

[ cabal ] hie-bios-0.2.0, hie-bios-0.1.1, hie-bios-0.1.0, hie-bios-0.7.3 (constraint
[ cabal ] from user target requires ==0.9.0)
[ cabal ] [__1] fail (backjumping, conflict set: ghcide, hie-bios)
[ cabal ] After searching the rest of the dependency tree exhaustively, these were the
[ cabal ] goals I've had most trouble fulfilling: hie-bios, ghcide
[ cabal ]

The command I tried: ghcup compile hls -v 1.6.1.0 --ghc 8.10.7 --ghc 9.0.2 --cabal-project-local https://gist.githubusercontent.com/hasufell/8409effe97d33c36369e4d9906556c1e/raw/0d6caaabaa974430c2c3b3ba68a4872d2a984dbf/gistfile1.txt

[hasufell]

ghcup compile hls -v 1.6.1.0 --ghc 8.10.7 --ghc 9.0.2 --cabal-project-local https://gist.githubusercontent.com/hasufell/8409effe97d33c36369e4d9906556c1e/raw/0d6caaabaa974430c2c3b3ba68a4872d2a984dbf/gistfile1.txt

ghcup compile hls -g master --ghc 8.10.7 --cabal-project-local https://gist.githubusercontent.com/hasufell/8409effe97d33c36369e4d9906556c1e/raw/0
d6caaabaa974430c2c3b3ba68a4872d2a984dbf/gistfile1.txt

You can't build 8.10.7 and 9.0.2 in one go, because 9.0.2 needs --cabal-project cabal-ghc90.project.

[Abastro]

Oh, I see. Thank you!

[Abastro]

Seems like installing the master branch did the trick. Anyway, thanks! (Still, would be grateful for the formal release)
EDIT: The local file does not work for ghc9.0.2 ..

[hasufell]

who has an overview of that GHCs are to be supported?

These two files will need adjustment:

1. https://github.com/haskell/haskell-language-server/blob/master/bindist/ghcs
2. https://github.com/haskell/haskell-language-server/blob/master/bindist/ghcs-FreeBSD

[pepeiborra]

Good point, we'll need to add support for GHC 9.2.2 before the 1.7.0 release.

[hasufell]

Good point, we'll need to add support for GHC 9.2.2 before the 1.7.0 release.

9.2.2 is broken on windows ... not sure it's worth the support.

[Abastro]

How about GHC 9.2.1?

[hasufell]

9.2.1 has severe bugs in native M1 code generator. I'm not totally sure if 8.10.7 with llvm backend is better, though.

https://downloads.haskell.org/~ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html gives some.overview

[georgefst]

As discussed in #2763 (comment), the functionality added in that PR is possibly in a weird state, of being implemented but not supported by editor integrations. It would be a shame to release it like that, so it would be great to get some help from someone who knows more about how plugin-specific options work.

[michaelpj]

I think we can do that after releasing the server if we need to. Having the option isn't harmful by itself.

[jrp2014]

Does this release support Apple M1 Macs natively (ie, not just through LLVM). Sorry if this has been answered multiple times before.

[hasufell]

I suggest to move forward with the release and not let the vscode extension block it.

The only decision that needs to be made for that is whether we still distribute the static binaries on the github release page. I'd vote for no (especially since that logic is removed from the github workflow). The extension currently would ignore the newly uploaded make-based tarballs afais (because the asset name doesn't match): https://github.com/haskell/vscode-haskell/blob/70f6883af669ef176fe3cf8ec4963921de686f79/src/hlsBinaries.ts#L382-L413

So we can just go ahead.

[pepeiborra]

I can do the HLS release this time, but I will need hackage permissions for the many packages.

@wz1000 are you still good to do the 1.7.0 release?

[wz1000]

Yes, I will do the release this week.

[wz1000]

All the binary and hackage releases have been made.