Automate hackage releases

[jneira]

• From the recent experience we know that:
  • Users needs a hackage release for every github release we do: Will 0.9.0 and future releases be uploaded to hackage? #1282
  • The hackage release is cumbersome and error prone and involve the coordination of several contributors, see prepare 0.9.0 hackage release #1287 and Upload to Hackage #1175
• So we have to automate the process as much as we can, making the automating process itself lightweight if possible

The steps needed to make the release are:

1. Identify changes of each subpackage and check if they can break downstream ones
2. Bump up the package version accordingly and propagate it to the bounds of downstream packages
3. Make pr(o several prs) with those changes, ensuring the order of dependencies
4. Cherry pick those changes onto the github release commit as a branch
5. Check the subpackage builds succesfully in that branch (and test it?)
6. Do a cabal check && cabal haddock subpackage && cabal sdist subpackage
7. Do a cabal upload subpackage (we can use https://github.com/haskell-actions/hackage-publish)

I think the steps 5, 6 and 7 could be automated in ci, uploading package candidates to do a final review and publish all of them.

Not sure how could we automate 1-4 though. Maybe doing a git diff per subpackage and update version bounds of .cabal files with some form of grep&sed (bumping out version as always breaking with no fine grained pvp considerations as suggested by @michaelpj)

There are projects with lot of subpackages and maybe they have been some work to automate this, as pointed by @wz1000.
For example amazonka. Afaics they have a Makefile that includes upload of packages: https://github.com/brendanhay/amazonka/blob/develop/Makefile

[ndmitchell]

Note that step 1 is optional. The PVP says you MUST increase the bounds IF you have incompatible changes. There's nothing to stop you increasing the bounds ALWAYS. Moreover, I don't see a huge heap of value in keeping the bounds as broad as possible, given we do a monolithic release, and people should always use the latest stuff together.

I'd simplify by writing tooling to bump all bounds, including propagating downstream dependency bounds, in one atomic go.

What special testing should a release get? Ideally none, because we're so confident in our tests :)

[michaelpj]

Neil said exactly what I tried to say on the other issue but much better :)

As another angle: we don't gain anything much from fine-grained bounds wrangling between plugins. At best, that might allow someone to use a newer version of a plugin with an old version of HLS. But do we actually care much about this usecase? If the versions of HLS and the plugins move in lockstep (as if they were one package!)... would anyone actually mind? I don't think so. Maybe later in the future we might care about this.

So my vote goes to: one version for HLS and all the plugins (all the plugins in this repo, anyway).

[pepeiborra]

But note that bumping everything up and propagating all the way up to the haskell-language-server.cabal descriptor only works if all the packages are uploaded to Hackage at the same time. Plugins that have not been uploaded to Hackage after bumping will be filtered out by cabal install haskell-language-server, assuming the flags stay flexible, or make the cabal solver fail if the flags become rigid. So automating cabal upload is a hard pre-requisite.

[jneira]

At best, that might allow someone to use a newer version of a plugin with an old version of HLS.

Well i can imagine some users could assemble their version of the hls executable to use our plugins and some private ones.
They will not be able to stick to an older ghcide version (maybe cause their plugins would be broken) and get plugin fixes, as we will bump everything and all plugins will require last ghcide/hls-plugin-api version even if they work against the older ones.

But i dont know if that use case exists in the real world tbh so we can wait for real requests.

So if we bump up everything (including package with absolutely no changes? that seems weird for me) we could do it as part of the github release project, for example.

[michaelpj]

I tried to build HLS 0.9 from Hackage today. Cabal picked ghcide-0.7.5.0, which HLS doesn't actually compile against due to it including some of the hiedb changes.

Now, we can constantly keep adding upper bounds to things when we notice problems like this... or we can accept the reality that the packages in this project are all tested together in a single version configuration, and installing anything else is unlikely to work.

My proposal is still to just give everything the same version X and require ghcide == X and so on everywhere. This is effectively an expanded version of what would happen if all the libraries were all public libraries of the same cabal package, which would IMO be a much better fit as soon as we can actually put such packages on Hackage...

[pepeiborra]

Proposal sounds reasonable! Do we have any volunteers to implement it?

For the time being, I have made a Hackage revision with the updated constraints.

[jneira]

well if we all agree in do it that way, we could do it in the next hls release

[michaelpj]

For the time being, I have made a Hackage revision with the updated constraints.

Sadly, ^>=0.7.3 appears to mean 0.7.3 < x < 0.8, rather than 0.7.3 < x < 0.7.4...

[pepeiborra]

Revised it to ==0.7.3, sorry about that

[michaelpj]

The plugins which depend on ghcide also need those bounds 😅 Otherwise you get both versions of ghcide being built, and the plugin depends on the new one and fails.

At this point I think it's maybe not worth fixing it and we should just try the "pin everything to one consistent version" approach for the next release.

[pepeiborra]

That seems surprising, shouldn't Cabal try to come up with a plan that only builds every package once, if possible?
If that's not the default, are there any Cabal flags that can be used to enforce such behaviour?

[michaelpj]

Ignore me: on closer inspection I was still getting ghcide-0.7.4 as a dependency of haskell-language-server itself, somehow I'm still not getting the Hackage revision or something. I do see ghcide-0.7.3 being built too, but I think that might be for an executable instead.