HLS 2.6.0.0 #166
HLS 2.6.0.0 #166
Conversation
wz1000
force-pushed
the
wip/hls-2.6.0.0
branch
from
8bf3a1b to
3c173ef
Compare
|
|
|
From the README:
However, this PR only made the additions to |
|
Yes, the readme is outdated. The current working mode is: upstream maintains If you want the quickest releases possible, use vanilla, but also be aware that they don't go through any QA from ghcup. As a result, a large portion of GHC bindists are broken in the vanilla channel. |
| @@ -5804,6 +5803,101 @@ ghcupDownloads: | |||
| dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-aarch64-apple-darwin.tar.xz | |||
| dlSubdir: haskell-language-server-2.5.0.0 | |||
| dlHash: 2e5083ebf7fc9dd3c5aa31059f9336bec4407fffb21b93a20decb49e9cf880a4 | |||
| 2.6.0.0: | |||
| viTags: | |||
| - Latest | |||
There was a problem hiding this comment.
In the vanilla channel, the policy used to be that Latest == Recommended. Why break this invariant?
There was a problem hiding this comment.
Where is this documented?
There was a problem hiding this comment.
In all the previous patches I've made, I've always added exactly the same things to both the vanilla and default yamls, including updating or not updating the Recommended tag.
There was a problem hiding this comment.
Yes, we should enforce reviews. I hope @runeksvendsen will give us a hand with that.
Edit: as well as improving documentation
There was a problem hiding this comment.
@hasufell I'm happy to assist in reviewing, but that requires that PRs be open for longer before being merged. Looks like this PR was merged less than 48 hours after being opened. I'm working part time on GHCup, so I don't have time every day to look at tickets/PRs.
There was a problem hiding this comment.
@runeksvendsen yes... I started to enforce review through branch protection rules.
Previously I had signalled that WT can raise and merge PRs on their own, since it wasn't clear whether I'll continue to maintain things on my own or at all.
So no one is to blame here. We'll just switch things up from now on.
There was a problem hiding this comment.
Previously I had signalled that WT can raise and merge PRs on their own, since it wasn't clear whether I'll continue to maintain things on my own or at all.
Who/what is WT?
| FreeBSD: | ||
| unknown_versioning: | ||
| dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.6.0.0/haskell-language-server-2.6.0.0-x86_64-freebsd.tar.xz | ||
| dlSubdir: haskell-language-server-2.6.0.0 | ||
| dlHash: 8d172261b2b2b2fb09572589b192245a5e306e34f3f4e2b92af4fdb565564a99 |
There was a problem hiding this comment.
This is erroneous.
The vanilla channel does not support the FreeBSD GHC versions that this HLS bindist supplies. You're building the HLS bindists against the main channel, but then add it to the vanilla-channel, which doesn't add up.
You have to build against the vanilla channel in HLS release CI, so that the configuration matches properly.
There was a problem hiding this comment.
You have to build against the vanilla channel in HLS release CI, so that the configuration matches properly.
Then these bindists will only be usable by people using the vanilla channel. Why even build HLS bindists officially in that case? It seems like you are suggesting that ghcup will take the responsibility of building all HLS bindists.
There was a problem hiding this comment.
Then these bindists will only be usable by people using the vanilla channel.
Well, the channel has to be self-consistent. It is an alternative to the default channel. It's not meant to be added on top of the default channel.
It seems like you are suggesting that ghcup will take the responsibility of building all HLS bindists.
Yes, that's what I'm planning to do: haskellfoundation/tech-proposals#61
There was a problem hiding this comment.
We will build HLS bindists against the vanilla channel next time, but it is basically impossible to distribute those bindists as switching channels is not safe.
There was a problem hiding this comment.
This is how all linux distributions with different sources work.
There is no plan to make more complicated abstractions to support users randomly switching between channels.
HLS already does ABI checks on startup.
GHCup maintainers discourage the use of the vanilla channel for reasons explained in the tech proposal.
No description provided.