search

snoyberg / mono-traversable

Type classes for mapping, folding, and traversing monomorphic containers
155 stars 64 forks source link

Build failure of mono-traversable-1.0.15.2 with GHC 9.2 #198

Closed andreasabel closed 3 years ago

andreasabel commented 3 years ago

I think mono-traversable-1.0.15.2 should get a revision with a bound base < 4.16 since it does not build with GHC 9.2; Option was removed.

Building library for mono-traversable-1.0.15.2..
[1 of 6] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, dist/build/Data/MonoTraversable.o, dist/build/Data/MonoTraversable.dyn_o )

src/Data/MonoTraversable.hs:97:35: error:
    Module ‘Data.Semigroup’ does not export ‘Option(..)’
   |
97 | import Data.Semigroup (Semigroup, Option (..), Arg)
   |                                   ^^^^^^^^^^^
snoyberg commented 3 years ago

I'm happy to give out Hackage maintainer bits if someone else wants to play around with this stuff. But I personally won't spend my time on revisions.

andreasabel commented 3 years ago

I'm happy to give out Hackage maintainer bits if someone else wants to play around with this stuff.

I would like to step in, I am AndreasAbel on hackage.

snoyberg commented 3 years ago

I've added you on Hackage.

andreasabel commented 3 years ago

Thanks!

I made the revisions for 1.0.15.1/2, the .0 had already an upper bound on base.

My general take is that upper bounds (esp. on base) should only set when there is evidence of failure. In practice, this means that upper bounds are mostly set in revisions.

The more "paranoid" approach is to generally set an upper bound on base and only relax it when there is evidence of success. However, I think this technique produces a lot of friction in the ecosystem where maintainers have to be constantly pestered to relax upper bounds.

So my philosophy is: don't put an upper bound on base in releases, add it in revisions later if needed.