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.

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

[Chore] Build with LTS-21.0, prepare a release #289

Merged
merged 9 commits into from
Jul 4, 2023

Conversation

Martoon-00
Copy link
Member

@Martoon-00 Martoon-00 commented Jun 23, 2023

We want to make universum work with the recent LTS-21.0, that would at least be helpful for Morley project.

So make CI test against the most recent GHC version, do the necessary changes.
The prepare the next release.

Description

Related to #288

Related issues(s)

Fixed #

✓ Checklist for your Pull Request

Ideally a PR has all of the checkmarks set.

If something in this list is irrelevant to your PR, you should still set this
checkmark indicating that you are sure it is dealt with (be that by irrelevance).

  • I made sure my PR addresses a single concern, or multiple concerns which
    are inextricably linked. Otherwise I should open multiple PR's.
  • If I added/removed/deprecated functions/re-exports,
    I checked whether these changes impact the .hlint.yaml rules
    and updated them if needed.

Related changes (conditional)

  • Tests

    • If I added new functionality, I added tests covering it.
    • If I fixed a bug, I added a regression test to prevent the bug from
      silently reappearing again.
  • Documentation

    I checked whether I should update the docs and did so if necessary:

  • Record your changes

    • I added an entry to the changelog if my changes are visible to the users
      and
    • provided a migration guide for breaking changes if possible

Stylistic guide (mandatory)

  • My commit history is clean (only contains changes relating to my
    issue/pull request and no reverted-my-earlier-commit changes) and commit
    messages start with identifiers of related issues in square brackets.

    Example: [#42] Short commit description

    If necessary both of these can be achieved even after the commits have been
    made/pushed using rebase and squash.

✓ Release Checklist

  • I updated the version number in universum.cabal.
  • I updated the changelog and moved everything
    under the "Unreleased" section to a new section for this release version.
  • If any definitions (functions, type classes, instances, etc) were added,
    I added @since haddock annotations.
  • (After merging) I created a new entry in the releases page,
    with a summary of all user-facing changes.
    • I made sure a tag was created using the format vX.Y.Z

@Martoon-00 Martoon-00 changed the title [Chore] Prepare a release [Chore] Build with LTS-21.0, prepare a release Jun 23, 2023
@lierdakil
Copy link
Contributor

Uh. You forgot to bump stack's ghc version in ci.yml. Also might as well bump stack version while at it.

@lierdakil
Copy link
Contributor

WTH, Windows build dies horribly while trying to link tests on 9.4.5.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
@Martoon-00
Copy link
Member Author

WTH, Windows build dies horribly while trying to link tests on 9.4.5.

Do you think Morley can wait for this to me properly resolved by devops, or we better try to invent a workaround, e.g. ignore Windows support?

@lierdakil
Copy link
Contributor

properly resolved by devops

Frankly, I'm not entirely convinced there's something "to be properly resolved" here, I've since seen GHC 9.4.5 segfaulting on Windows when trying to build stuff, too, so probably it's just that 🤷 Sigh. I can take a closer look though, if you want. The first thing I'd suggest trying is building with -fasm instead of -fllvm.

Do you think Morley can wait

Honestly, I just want to get the update over with, so I can play around with the cool stuff like Char kind and OverloadedRecordDot. FWIW, this here's not the only blocker for Morley.

But arguably we want to push out the release sooner rather than later, if for no other reason than Universum not being on Stackage means Hoogle doesn't index it and that's annoying 😒

@Martoon-00
Copy link
Member Author

I can take a closer look though, if you want.

Can I offload this to you to try then?

Or I could go with your guesses, but it would definitely take more time.

@lierdakil
Copy link
Contributor

Can I offload this to you to try then?

Sure

@lierdakil
Copy link
Contributor

Oh well, apparently it was just cabal 3.6 not playing ball with newer ghc.

universum.cabal Outdated Show resolved Hide resolved
Copy link
Contributor

@lierdakil lierdakil left a comment

Choose a reason for hiding this comment

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

Other than the note about bumping GHC's patch-versions we're testing with, LGTM.

CHANGES.md Outdated Show resolved Hide resolved
Problem: we aim at supporting the recent LTS-21.0 which uses GHC-9.4.5.

That is two minor versions ahead from the recent GHC we currently test
with, so let's include GHC-9.4.5 in the list too.

Solution:
* add `GHC-9.4.5` to our `ci.yml`
  + also update used `stack` version by the way
* remove the oldest `GHC-8.6.5`
* update `tested-with` section in `.cabal` file accordingly
Problem: apparently after the recent addition of `Eq` superclass to
`Hashable` and our attempts to fix that in
be02075, some redundant constraints
remained (GHC does not always recognize redundant constraints).

With GHC-9.4 this brings us warnings.

Solution: use `MIN_VERSION` pragma to remove `Eq` constraint for
`hashable >= 1.4.0`.
Problem: one import is necessary for the rewrite rule, and this rule is
disabled for `text >= 2.0.2`.

Solution: disable the import conditionally in the same way.
@Martoon-00 Martoon-00 force-pushed the martoon/new-release branch 2 times, most recently from af8c977 to 0b9fe96 Compare June 28, 2023 16:10
@Martoon-00
Copy link
Member Author

Just in case: @gromakovsky would you like to check this once again, or I can merge?

@lierdakil
Copy link
Contributor

ping @gromakovsky @Martoon-00 can we get this over with? 😅

@gromakovsky
Copy link
Member

Oh, let me look now 👀

universum.cabal Outdated
ScopedTypeVariables
TypeOperators
Copy link
Member

Choose a reason for hiding this comment

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

A couple of nitpicks:

  1. According to this page, ExplicitNamespaces is implied by TypeOperators. Is it necessary to enable it explicitly?
  2. Since TypeOperators is enabled for almost each component, it might be to put it into common-options.

Copy link
Member Author

Choose a reason for hiding this comment

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

That makes sense, changed.

@gromakovsky
Copy link
Member

Solution: bump the version from 1.8.1.2 to 1.8.2, since we started exporting ~. Whether is this a breaking change or not - is arguable, but let's play it safe.

What do you mean by "safe"? AFAIK when you increase c in a.b.c, it means that changes are non-breaking. My interpretation of "safe" is "let's mark it as breaking, because marking non-breaking as breaking is safer than marking something breaking as non-breaking".
FTR I think it's not a breaking change, so I don't mind setting 1.8.2.

Copy link
Member

@gromakovsky gromakovsky left a comment

Choose a reason for hiding this comment

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

I've suggested a couple of small changes, I think they are not important and can be considered optional, so feel free to merge.

@lierdakil
Copy link
Contributor

when you increase c in a.b.c, it means that changes are non-breaking

Hackage PVP is rather specific in what it calls "breaking changes":

If any entity was removed,

nope

or the types of any entities or the definitions of datatypes or classes were changed,

also no

or orphan instances were added or any instances were removed,

not to my knowledge

then the new A.B MUST be greater than the previous A.B.

Although, that all includes dependencies, and that all gets rather vague with instances in base when allowing multiple versions.

@gromakovsky
Copy link
Member

So long story short, 1.8.2 should be fine and we don't need 1.9.0 AFAIU.

Martoon-00 and others added 6 commits July 4, 2023 19:15
Problem: nowadays `~` is not a built-in operator, rather a definition
coming from `Data.Type.Equality`.

This makes `VarArg` module fail.

Solution: add a conditional import to `VarArg` module.

Also, start re-exporting the `~` operator from universum.
Problem: `universum` has been excluded from the recent LTS, at least
because we do not support the most recent version of `text` package.
This issue with `text` has been fixed, and we need a new version with
the fix.

Solution: bump the version from `1.8.1.2` to `1.8.2`, since among
changes in definitions we only started exporting `~`.
Problem: the comment in the CI config says "Use only the latest compiler
on non-Linux", but GHC 8.10.7 is also included for some reason.

Solution: exclude it.
Problem: older versions of GHC we test against have got new patches,
and new versions `9.0.2` and `9.2.8` are supported.

Solution: test against them in CI.
Problem: it's not really fixed anywhere, whether should we have an empty
`Unreleased` section in our changelog, or better go without it.

Solution: we agreed with @Gromak that it's better to leave no empty
section (so that it does not appear on Hackage).

So as a clarification, on our PR template I change the point about
changelog (for regular PRs, not as part of release routine) to mention
the creation of `Unreleased` section if it is absent.
@Martoon-00 Martoon-00 merged commit b9031ef into master Jul 4, 2023
@Martoon-00 Martoon-00 deleted the martoon/new-release branch July 4, 2023 16:24
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.

3 participants