-
-
Notifications
You must be signed in to change notification settings - Fork 389
Automate hackage releases #1310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 :) |
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). |
But note that bumping everything up and propagating all the way up to the |
Well i can imagine some users could assemble their version of the hls executable to use our plugins and some private 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. |
I tried to build HLS 0.9 from Hackage today. Cabal picked 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 |
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. |
well if we all agree in do it that way, we could do it in the next hls release |
Sadly, |
Revised it to |
The plugins which depend on 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. |
That seems surprising, shouldn't Cabal try to come up with a plan that only builds every package once, if possible? |
Ignore me: on closer inspection I was still getting |
This is the plan cabal computes for me. It includes only ghcde-0.7.3 as expected:
|
Just an annoyance about this that occurred to me: for cabal to be happy we'd have to pick a version higher than any version used by any of the packages currently, and some of the plugins are already at 1.something, so we'd have to go into the major version 1 era for HLS. Not sure how we feel about that (IMO it's easily v1-worthy). |
I was thinking in that lately, I think it is a good moment to let hls be (young) adult Maybe we could do the definitive bound to 1.0 for all packages just before the incoming GitHub release |
I'm good for that, especially if <1 version causes some problems.
BTW, @michaelpj, which plugin did you mean? It looks like at least in HLS repo there is no plugin with the major version 1... |
Now that the 1.0 release is complete, are there any plans to actually upload it to Hackage? |
I am working on this here: https://github.com/jneira/haskell-language-server/tree/release-hackage |
The steps needed to make the release are:
cabal check && cabal haddock subpackage && cabal sdist subpackage
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
The text was updated successfully, but these errors were encountered: