Skip to content

Prepare release 1.7 #2834

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

Merged
merged 4 commits into from
Apr 21, 2022
Merged

Prepare release 1.7 #2834

merged 4 commits into from
Apr 21, 2022

Conversation

wz1000
Copy link
Collaborator

@wz1000 wz1000 commented Apr 18, 2022

Waiting for haskell.org to come back...

Copy link
Collaborator

@konn konn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as for Splice Plugin!

Copy link
Collaborator

@fendor fendor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, awesome!

@fendor
Copy link
Collaborator

fendor commented Apr 18, 2022

Actually one question, don't we have to bump the versions of all plugins? Since we are modifying their dependency requirements and have to re-upload them to hackage?

@wz1000
Copy link
Collaborator Author

wz1000 commented Apr 18, 2022

Actually one question, don't we have to bump the versions of all plugins? Since we are modifying their dependency requirements and have to re-upload them to hackage?

No, I believe hackage revisions should be sufficient for the rest of the plugins.

@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch from 3ae38b3 to f31ea85 Compare April 18, 2022 10:53
@July541
Copy link
Collaborator

July541 commented Apr 18, 2022

It would be great if we can bundle hls-stylish-haskell-plugin in ghc 9.2 with the new release. #2836

And, should we enabling it in ghc9.0 with a compromise solution? #2820

@hasufell
Copy link
Member

@wz1000 try

ghcup config set url-source '{"OwnSource": "https://mirror.sjtu.edu.cn/ghcup/yaml/ghcup/data/ghcup-0.0.6.yaml"}'

to enable a mirror.

@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch from f31ea85 to 9fca35d Compare April 18, 2022 11:05
@wz1000
Copy link
Collaborator Author

wz1000 commented Apr 18, 2022

@wz1000
Copy link
Collaborator Author

wz1000 commented Apr 18, 2022

It would be great if we can bundle hls-stylish-haskell-plugin in ghc 9.2 with the new release. #2836

Sure , we can include this PR.

And, should we enabling it in ghc9.0 with a compromise solution? #2820

Its not exactly clear to me what the compromise is.

@July541
Copy link
Collaborator

July541 commented Apr 18, 2022

Its not exactly clear to me what the compromise is.

The stylish-haskell 9.0 branch is on my fork, migrate to the official repo is not cheap.

It is worth waiting if we are not eager. #2820 (comment)

@pepeiborra
Copy link
Collaborator

Actually one question, don't we have to bump the versions of all plugins? Since we are modifying their dependency requirements and have to re-upload them to hackage?

No, I believe hackage revisions should be sufficient for the rest of the plugins.

policeman (build from HEAD) is great for reviewing version bumps, but sadly I have found it doesn't work very well for HLS. If you find a way to make it work nicely, please share!

@michaelpj
Copy link
Collaborator

No, I believe hackage revisions should be sufficient for the rest of the plugins.

Is this a good idea? Won't that make the previous version unbuildable? Since the versions of the plugins which worked with it before will now not work with it since you'll have mutated the version bounds.

Copy link
Member

@Ailrun Ailrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Here's my minor comment:

- Distribute dynamically linked binaries for HLS to avoid statically linking against GLIBC
and system libraries, and to avoid unpredictable failures due to subtle differences
between the GHC used to compile HLS and the GHC installed on the users machine
(@hasufell, #2675, #2431)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that is needed, since the same caveats about static binaries apply. The difference is that this time we aren't distributing static binaries but are distributing dynamic binaries. If someone tries to compile static binaries on their own then the caveat still applies (and they will get a warning popup).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wz1000 I mean, the document mentions "local building" as the easiest way to get a dynamic binary, but now it's probably easier to just download the binary.

@pepeiborra
Copy link
Collaborator

No, I believe hackage revisions should be sufficient for the rest of the plugins.

Is this a good idea? Won't that make the previous version unbuildable? Since the versions of the plugins which worked with it before will now not work with it since you'll have mutated the version bounds.

I second this, previous versions would not become unbuildable if the change was only increasing the upper bound. I question the choice of clamped ^> version bounds.

@wz1000
Copy link
Collaborator Author

wz1000 commented Apr 18, 2022

Is this a good idea? Won't that make the previous version unbuildable? Since the versions of the plugins which worked with it before will now not work with it since you'll have mutated the version bounds.

I second this, previous versions would not become unbuildable if the change was only increasing the upper bound. I question the choice of clamped ^> version bounds.

Thanks for noticing this, I will relax the bounds on the plugins which haven't been bumped.

Copy link
Collaborator

@eddiemundo eddiemundo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Collaborator

@isovector isovector left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm for tactics

@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch from 9fca35d to fb983b8 Compare April 19, 2022 07:34
@wz1000
Copy link
Collaborator Author

wz1000 commented Apr 19, 2022

I have relaxed the bounds on all the packages for which the version wasn't bumped.

@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch 5 times, most recently from 9337f58 to 7e1c11e Compare April 20, 2022 07:38
@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch from 7e1c11e to 5845c7d Compare April 20, 2022 09:19
@wz1000 wz1000 force-pushed the wip/1.7-release-prep branch from 5845c7d to 4592162 Compare April 20, 2022 11:06
@wz1000 wz1000 merged commit 641eed4 into master Apr 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants