prepare 0.9.0 hackage release

[jneira]

Package Checklist:

package	@	update .cabal	upload
ghc-exactprint	@alanz	N/A	☑
hie-compat?	@wz1000	N/C	N/C
hls-plugin-api	@jneira	#1290	☑
ghcide	@pepeiborra	#1289	☑
hls-class-plugin	@Ailrun	N/C	N/C
hls-eval-plugin	@jneira	#1305	☑
hls-explicit-imports-plugin	@pepeiborra	N/C	N/C
hls-haddock-comments-plugin	@berberman	#1292	☑
hls-hlint-plugin	@jneira	#1296	☑
hls-retrie-plugin	@pepeiborra	#1288	☑
hls-splice-plugin	@konn	#1293	☑
hls-tactics-plugin	@isovector	N/C	N/C
hls		☐ (bounds)	☑

• I've linked each package with the last collaborator that uploaded it to hackage (and/or from Upload to Hackage #1175), feel free to comment or ping me if you think you should not be there. Thanks all!
• Each .cabal update should be done in a pr and cherry-picked to the 0.9.0-hackage branch (like the last time)
• Ideally we should set a lower bound over hls-plugin-api/ghcide in plugins if they need the new version to compile (so they should be bumped out first)
• The release would close this and Will 0.9.0 and future releases be uploaded to hackage? #1282

I used this for checkboxes

• ☐
• ☑
• N/C = no changes (verified via git log )

[Ailrun]

The only change in hls-class-plugin since the last release is a part of hiedb PR. It should not be released until HLS release actually includes it; that being said, there's nothing to upload for hls-class-plugin for 0.9.0

[pepeiborra]

There are no worthwhile changes in ghcide since the 0.7.2 release, other than the hiedb patch.
Or are we aiming for some kind of parity with the binary release?

[alanz]

The plan was to get ghcide out before hiedb lands, so we have a month to dogfoof hiedb before it goes into a tagged release

[pepeiborra]

We discussed that in the hiedb PR and since there had been a ghcide release recently, decided not to make another one

[jneira]

Or are we aiming for some kind of parity with the binary release?

not necessarily imo

[jneira]

@pepeiborra But hls-plugin-api has a new config field maxCompletions so it need a breaking bump, that it turns need a new lower bound in ghcide over hls-plugin-api cause it is using the new field, but it can be done with a hackage revision,

blessed transitive dependencies 😄

[pepeiborra]

Ok, in that case let's do a ghcide release as well. I'll update the changelog and then back port it to the commit before the hiedb patch

[alanz]

http://hackage.haskell.org/package/ghc-exactprint-0.6.3.4

[berberman]

hls-haddock-comments-plugin is uploaded.
Off topic: @jneira sorry to disturb you here, I didn't receive the mention because you misspelled my username...

[jneira]

oops sorry, corrected now

[konn]

I've just uploaded hls-splice-plugin-0.2.0.0: https://hackage.haskell.org/package/hls-splice-plugin-0.2.0.0 !

[jneira]

I am gonna try to update hls-eval-plugin

[jneira]

@beberman @konn a last request: what commit have you uploaded to hackage? It would be great to tag it in the repo with the plugin name and the version (hlint-splice-plugin-0.2.0.0 for example), so users can checkout the precise commit easily. Feel free to make the tag if you have permissions to do it, or note the commit... thanks!

[jneira]

hls-plugin-api released:

• hackage: https://hackage.haskell.org/package/hls-plugin-api-0.7.0.0
• cherry picking baf8f04 on the 0.9.0-hackage branch as b613280
• tag: https://github.com/haskell/haskell-language-server/tree/hls-plugin-api-0.7.0.0

[berberman]

@jneira Should I tag the origin commit 4d67d18 on master or the new cherry-picked commit on 0.9.0-hackage?

[jneira]

That was to ensure plugins can be built with the released version of deps: hls-plugin and ghcide
So it is has more sense for the latter two, to not break the rest of plugins.
If yours works with the released version of hls-plugin-api and ghcide it will be fine, but I would tag the commit for future reference.

[konn]

I've just noticed that lower bound for ghcide in hls-splice-plugin is not enough... I will correct revision on Hackage once ghcide gets released, and file a new PR corresponding new revision and tag on appropriate commit.
By the way, in a long term, it might be good to have some machinery to check if (hypothetical) Hackage release of related packages just compile or not, and then automatically upload them to Hackage once all the build success.

[jneira]

Yeah we have to automate this, to make hackage releases more agile.
I should made explicit the steps to make the releases in this issue (following how we did for 0.8.0), sorry.

[tittoassini]

Apologies for the delay, I have been busy the last few days and I had forgotten about this thread :-(

I agree that it would be better to automate this step.

I have uploaded hls-eval-plugin-0.2.0.0 to hackage.

[jneira]

ghcide released:

• hackage: https://hackage.haskell.org/package/ghcide-0.7.3.0
• cherry picking d602e45 on the 0.9.0-hackage branch as b9c6869
• tag: https://github.com/haskell/haskell-language-server/tree/ghcide-v0.7.3

//cc @pepeiborra @konn

[pepeiborra]

Thank you @jneira !
I will upload my plugins over the weekend

[jneira]

hls-hlint-plugin released:

• hackage: https://hackage.haskell.org/package/hls-hlint-plugin-0.2.0.0
• cherry picking 8c7b97b on the 0.9.0-hackage branch as b1ca9b3
• tag: https://github.com/haskell/haskell-language-server/tree/hls-hlint-plugin-0.2.0.0

[jneira]

@konn
I've tried to build hls-splice-plugin-0.2.0.0 with ghcide-0.7.3 and i am afraid it fails:

src\Ide\Plugin\Splice.hs:394:23: error:
    • Variable not in scope:e:
        rangeToRealSrcSpan :: NormalizedFilePath -> Range -> RealSrcSpan
    • Perhaps you meantnt ‘getRealSrcSpan’ (imported fromfrom GhcPlugins)
    |
394 |             let spn = rangeToRealSrcSpan fp ran
    |                       ^^^^^^^^^^^^^^^^^^

The goal of the step described in the issue description

Each .cabal update should be done in a pr and cherry-picked to the 0.9.0-hackage branch (like the last time)

was try to avoid those errors. The plugin is adapted to ghcide master and no ghcide-0.7.3.

So maybe we should make changes in cascade hls-plugin-api -> ghcide -> plugins.

To fix it i am afraid that we will have to make another release with a version built as described (and make the actual version non preferred)

[konn]

Oops, sorry for my terrible mistake... I think we can avoid cascade changes, if I just make hls-splice-plugin-0.2.0.0 deprecated, filing release-only PR to release-0.9.0 branch based on the version of hls-splice-plugin before the migration of rangeToRealSrcSpan to ghcide, mark this as hls-splice-splugin-0.3.0.0.

[jneira]

sounds good, thanks and no worries, we have to try make this process less error prone

I think we can avoid cascade changes

I wanted to mean that we should do changes on cascade for future releases

[jneira]

Fortunately, the rest of uploaded plugins works against released versions of hls-plugin-api and ghcide, tested locally with cabal get plugin && cd plugin && cabal build

• hls-eval-plugin
• hls-haddock-comments-plugin
• hls-hlint-plugin (as expected as it was the 0.9.0 version with .cabal changed)

[berberman]

I cherry picked 4d67d18 as 3bef14c on 0.9.0-hackage, and tagged it with hls-haddock-comments-plugin-0.1.1.

But the git said:

To github.com:haskell/haskell-language-server.git
 * [new tag]           ghcide-0.7.0.0 -> ghcide-0.7.0.0
 * [new tag]           hls-haddock-comments-plugin-0.1.1 -> hls-haddock-comments-plugin-0.1.1

Perhaps there is a stale tag on my local repo called ghcide-0.7.0.0 and I just pushed it?

EDIT:

Sorry for that, I removed it.

[jneira]

Perhaps there is a stale tag on my local repo called ghcide-0.7.0.0 and I just pushed it?

Yeah, i've renamed the tag i did ghcide-0.7.0.0 to ghcide-v0.7.0 like the new ones done by @pepeiborra to make them uniform.
You can delete ghcide-0.7.0.0
(I usually do git push upstream mytag to no upload unwanted ones)

[konn]

Hmm... it seems the situation is more complex than I expected. It seems that rangeToRealSrcSpan is already exported by Development.IDE in ghcide 0.7.3 at least from Haddock on Hackage, but it fails to compile with ghcide 0.7.3... why? Ah, I miss-searched for realSrcSpanToRange instead of rangeToRealSrcSpan. I think I can fix the situation with the expected solution at first.

[konn]

I've just reflected hls-splice-plugin-0.3.0.0 to 0.9.0-hackage branch, mad a release on Hackage, and created a tag hls-splice-plugin-0.3.0.0. Since the version of Splice Plugin in master remains 0.2.0.0 yet, I will make another PR against the master branch with further version bump to hls-splice-plugin-0.4.0.0, without uploading it to Hackage. This is to make sure we make another release of hls-splice-plugin when 0.10.0 (or 1.0.0? 😄) is out.

EDIT: I forgot to summarise:

• hackage: https://hackage.haskell.org/package/hls-splice-plugin-0.3.0.0
• directly merged version bump PR into the 0.9.0-hackage branch as ae6b541
• tag: https://github.com/haskell/haskell-language-server/tree/hls-splice-plugin-0.3.0.0

[konn]

Ah, I've just realised that the maintainer and author field of the cabal remains old: my name and my address. Anyway, since I've already made a release of 0.3.0.0 and it might not take so long for regular monthly release for February to come, I think it would suffice to change those fields when one uploads 0.4.0.0 to Hackage.

[Ailrun]

mark this as hls-splice-splugin-0.3.0.0.

BTW, may I ask why did you bump the second version number for this fix?

[konn]

It's due to the tighten lower bound for ghcide. PVP says:

Note that modifying imports or depending on a newer version of another package may cause extra orphan instances to be exported and thus force a major version change.

(Note: emphasis is on my own)

[Ailrun]

I mean, 0.2.0.0 is already depending on a newer version of ghcide (it won't be built without it), and 0.3.0.0 is just a fix to make it explicit, right?

[konn]

Well, the problem was that it used unreleased API (rangeToRealSrcSpan) of ghcide, resulting an error. I just revived the old implementation of hls-splice-plugin with the old, custom equivalent implementation. Then, I tightened l.b. for ghcide just to avoid potential possible complication due to such API conflict... but, yes, it seems it poses no interface change and minor version bump DID suffice. I was just silly...

[Ailrun]

Sorry if my comment was felt aggressive. I didn't mean to blame you on that, but just want to ensure we are using a similar versioning policy.
Thank you for all the answers, and I believe I understand your reasoning.

[konn]

No problem! I should be more careful when I make next release. Thank you for pointing it out 😄

[pepeiborra]

@jneira what's left to do here?

[jneira]

not much, as all subpackages has been uploaded: change hls cabal file with the appropiate lower bounds, cherry pick it to 0.9.0-hackage and upload it

[pepeiborra]

Here is the candidate release: https://hackage.haskell.org/package/haskell-language-server-0.9.0.0/candidate

cabal build works without increasing any lower bounds. To check this, I removed all the other components from the cabal.project file and edited haskell-language-server.cabal to turn on all the plugins and make the flags manual.

[jneira]

@pepeiborra the candidate looks right, many thanks
I would bump up the subpackages lower bounds cause hls itself does not have so much content and ghcide+plugins mark the difference in the release. So if you can build hls-0.9.0 with the plugins released with 0.8.0, the changelog will lie a bit.

[pepeiborra]

@jneira that doesn't seem like a good reason to bump lower bounds to me...

[jneira]

I am fine with the actual version too, by default the build will take last versions of everything anyways.
But, do you want to not have to maintain the lower bounds or you are trying to get something concrete?

[pepeiborra]

I am not keen on sending yet another PR

[pepeiborra]

Published!