Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bump version bounds #188

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Bump version bounds #188

wants to merge 4 commits into from

Conversation

vmchale
Copy link

@vmchale vmchale commented Nov 12, 2019

This bumps version bounds.

@jneira
Copy link
Collaborator

jneira commented Nov 18, 2019

LGTM and there aren't big changes but i would like @quasicomputational or @ocharles take a look.

@jneira
Copy link
Collaborator

jneira commented Nov 20, 2019

Well, if nobody disagree i will merge in two days or so

@jneira jneira self-requested a review November 20, 2019 13:54
@quasicomputational
Copy link
Collaborator

A theoretical issue is that the Dhall Prelude imports are versioned, and that version isn't the same in dhall-haskell 1.26 and 1.27. But the things that are actually imported are identical in those two versions of the standard, so it actually works out OK.

Can you also bump dhall.nix (and the Stackage resolver) to 1.27, so that there's CI coverage for the new version, please? I'm okay with losing 1.26 coverage and that bound potentially bitrotting so long as the latest claimed compatible version is being tested.

quasicomputational
quasicomputational reviewed Nov 25, 2019
View reviewed changes
lib/DhallToCabal/ConfigTree.hs
@@ -33,7 +33,7 @@ instance ( Semigroup a ) => Semigroup ( ConfigTree cond a ) where

instance ( Monoid a ) => Monoid ( ConfigTree cond a ) where
mempty = pure mempty
mappend = liftM2 mappend
mappend = (<>)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This might be breaking GHC 7.10 compatibility; the warning is unfortunate but it's the least evil. I don't actually care too much about old GHCs, but bounds will need to be adjusted and I think @jneira does care about GHC 7.10.

Copy link
Collaborator

@jneira jneira Nov 25, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

No problem, i have already to keep my etlas specific fork with changes over ghc and cabal versions so updating the bounds here could be fine

@jneira
Copy link
Collaborator

jneira commented Dec 19, 2019

@vmchale only left two small changes, have you the time to adress them? if it is not he case i would try to do it

@noughtmare noughtmare mentioned this pull request May 25, 2021
Open
@jneira jneira removed their request for review August 3, 2021 11:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@quasicomputational quasicomputational quasicomputational left review comments

@jneira jneira jneira left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@vmchale @jneira @quasicomputational