Haskell-language-server: Meta: Monthly Release

Created on 13 Dec 2020  Â·  6Comments  Â·  Source: haskell/haskell-language-server

Historically, starting with haskell-ide-engine, we have done a monthly release.

And the logic was simple. When the end of the month came, we did a simple sweep through the code base at the time to update the cabal snapshot and stack files to up to date resolvers and deps, then tagged for release.

The whole point was to have a low-ceremony, low expectation, easy to do process.

We seem to have become bogged down recently, in that getting a release out is much more hassle than it needs to be.

Key points

  1. We are delivering an exe to our users
  2. We have CI running against our current master.

What is stopping us from doing it the way we always used to?

I think tying the release in to ghcide is an unnecessary slowdown, in terms of the monthly release. I do believe we should aim to sync up to the released ghcide version, but it should not be a prerequisite for the hls monthly release.

This is an opinion, not grounded in anything hard, open for persuasion in other directions.

discussion meta question

Most helpful comment

I'm just going to be annoying again and point out that this would be a lot easier if we merged ghcide into HLS :trollface:

All 6 comments

I agree in we should be able to separate ghcide and hls releases if we have a good reason to do it but i think there is still some value in try to sync them:

  • we allow some (maybe marginal) installation methods:

    • build from the source tarball generated by github (see https://github.com/haskell/haskell-language-server/issues/484)

    • maybe the nix installation could be simplified (not sure about that)

    • add hls as a source repository package in cabal (cabal doesn't handle submodules, afaik)

  • but more importantly we feel the pain of sync the releases so we will be inclined to try automating it

    • thanks to the incoming release we synced hls and ghcide ci builds for example, and that has been a good thingâ„¢

    • we could take ride of the submodule

    • and we will prepared for release hls in hackage/stackage and allow more installations methods, so we will reach more users

That said, maybe this time i should not include ghcide-0.6, but i was eager to leverage the work done there and include the tests enabled by @peterwicksstringfield at same time. Maybe i took the wrong decision, given we had a request for a minor release only with formatters bump.

@jneira You are managing the release at the moment, so I leave it in your hands.

But I do think we should strive for the principle that the release is not a big deal, master is always releasable, and it is just a matter of tagging it, for the benefit of downstream packagers, so there is a "standard" version every month.

the principle that the release is not a big deal, master is always releasable, and it is just a matter of tagging it

Gotcha :slightly_smiling_face:

I'm just going to be annoying again and point out that this would be a lot easier if we merged ghcide into HLS :trollface:

I'm just going to be annoying again and point out that this would be a lot easier if we merged ghcide into HLS

"Carthago delenda est"

Was this page helpful?
0 / 5 - 0 ratings