Meta: Monthly Release

[alanz]

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.

[jneira]

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 Releases source code should include ghcide #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

[jneira]

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.

[alanz]

@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.

[jneira]

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

Gotcha 🙂

[michaelpj]

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

[alanz]

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"

[jneira]

Hi, we are gonna do a new release, a little bit before the new month, as we want to make it before merging hiedb usage on master (see #704) .
The release has become a little bit more complex with the upload of all plugins and hls itself to hackage.

I think we should keep it separate and be able to do github only releases to make the process more agile.
We could start making hackage releases on demand.

Ideally several maintainers (well any of them) should be able to do the release, to achieve that we have to automatize and or document the steps. I am gonna try to update the existing release doc to help while doing the next release. Hopefully the next one could be done for another maintainer smoothly.

[alanz]

Sounds good to me.

For me it is about having one release a month, as a cadence, than about the exact timing.

And getting it automated is a great goal.

[jneira]

We are following the monthly candence and the hackage upload is being covered in other issues