Binary-only releases should still have a Hackage release

[fendor]

Binary-only releases, such as HLS 2.9.0.1, did so far not have an accompanying Hackage release.
This is fine for HLS itself, but leads to worse UX for GHCup which provides an interface for compiling HLS binaries from source using the ghcup compile hls interface.

The issue is when users want to build from source, for whatever reason, the users' instinct is going to be to use ghcup compile hls -v <version>. However, when using the -v flag, GHCup is going to build HLS from Hackage. If the <version> is a binary only release, such as 2.9.0.1, then the most straight forward GHCup invocation is going to fail, as we didn't upload that version to Hackage.

There are workarounds, such as using a git tag or using an older version that is on Hackage. However, that's way worse UX for GHCup user (for various reasons). While we could discuss whether we should build from Hackage, I think a hackage release is trivial for us to do, and avoids some confusion.
In particular, people are sometimes wondering why the latest release and the Hackage release are out-of-sync.

So, I am proposing to amend our release process for binary-only releases, to always include a Hackage release in the future, even though the release of 2.9.0.1 would be exactly the same as 2.9.0.0.

[fendor]

I don't know whether there was already a similar issue, and whether I simply forgot we already discussed this before.

[Bodigrim]

For the record, I usually aim for cabal install haskell-language-server, which indeed depends on having the latest release on Hackage. This is how I install any other Haskell executables and I don't see why HLS must be different. While in early days HLS evolved too rapidly, it seems to be mature enough now.

[michaelpj]

I agree with this. It's annoying that we have to bump the version number just for GHCup, but that's how it is, so we should release to Hackage too to avoid confusion.