policy on plugin / ormolu versions?

[aryairani]

Will HLS be on ormolu 0.5.2.x for a while?
(This is fine with me, I prefer the stability since we use ormolu to standardize our codebase.)
What's the project's policy wrt plugin version bumps?

Actually, do released binaries bundle ormolu 0.5.2.x now? I was assuming from the flake.lock that they did, but I don't actually know how that file is used, or whether it's used when releasing HLS binaries.

Thanks

[fendor]

Hi!

As far as I know, we don't have a policy. It just depends on whether some plugin maintainer decides to bump the version.
Do you have a policy in mind, perhaps?

Actually, do released binaries bundle ormolu 0.5.2.x now?

Unfortunately, there is currently no easy way to find that out. You can look at the constraint in the hls-ormolu-plugin.cabal and then cross-check with the index-state what version is most likely selected. The most reliable way, is likely constructing the build-plan locally for the GHC version you are interested in.

I was assuming from the flake.lock that they did,

Flakes are not used for releasing HLS.

[aryairani]

I'm not sure. I guess some that could be mixed and matched if you like them (and maybe some of these are already implicitly being followed):

• only update major version of plugins if updating major version of HLS
• have reproducible release builds so we can be certain of exactly what code is in each release
• HLS releases of a given version will have the same version of plugins regardless of OS
• know and publish the versions of plugins / embedded tools

My goal is to be able to have a team all use the same version of a formatter, so that we can have consistent formatting. I like being able to use the formatter that's built into HLS, to minimize the number of tools I personally have to deal with directly, but I don't know how to get us all on the same version. I'm not sure that even all being on the same version of HLS across different platforms gives the same functionality, but maybe it does. Maybe this applies to other plugins besides formatting; I'm not sure.

[fendor]

I think, we follow (1), (2) and (3) (modulo unix stuff), although we might not check that in CI. However, for (1), we basically only have major version releases except for some minor backports.

Independent of the goal to have a policy for the formatters, which still makes a lot of sense, you likely want to be independent of HLS version changes.

Using ghcup, you may compile HLS from source and specify exactly the formatter version you need:

ghcup compile hls --ghc 9.4.5 --version 2.0.0.0 --git-describe-version -- --ghc-options=-j12 --constraint="ormolu==0.7.1.0" 

This way, you make sure your custom HLS version has been compiled with ormolu 0.7.1.0 for GHC 9.4.5. Unless something unexpected happens, you can make sure even with later HLS versions that everyone is using the same formatter.

[aryairani]

Using ghcup, you may compile HLS from source and specify exactly the formatter version you need

Okay, I see. Yes I think we will go that route, building our own HLS; though I do wish we could just have https://github.com/haskell/vscode-haskell set up the software for us on a per-project basis.