Closed Vekhir closed 5 months ago
We're actually starting to plan out a release with both 9.6 and 9.8 compatibility. This may accelerate it.
Glad to hear that.
While it's good that we have some pressure to release a new version, I wonder whether this here could be achieved by just uploading a new revision to Hackage that allows mtl 2.3
. At least https://github.com/xmonad/xmonad-contrib/commit/4929da0eac4e1f477b0f77ef6fd60ce615ccb650 just shuffles around some dependencies
EDIT: Ah, I remember. Mtl 2.3 stopped exporing Control.Monad
everywhere, so e.g. Control.Monad.State
doesn't export when
…
As a general note, the Arch packages are independent of Hackage revisions, and we have our own way of getting around restrictive bounds. So if it was that, I'd make a PR for updating the bounds if that wasn't already done :)
Arch package maintainer here, we'd actually love a soonish release to bring in all the great development efforts of the past 2 years :cat: thank you all for the work.
@Vekhir @anthraxx apologies for taking our sweet time, but 0.18.0 is available on Hackage (and elsewhere) now!
Problem Description
Hi, the current hackage release of
xmonad-contrib
(0.17.1) does not build with GHC 9.6 and in particular mtl 2.3. This issue has been fixed on master since 4929da0eac4e1f477b0f77ef6fd60ce615ccb650. I'm working on updating the Arch packages to GHC 9.6 andxmonad-contrib
is one of the affected packages which in its current form does not compile. While backporting might be possible in this case, having a compatible release from your side is always preferable. There isn't much of time pressure anyway - but perhaps it might make sense to start thinking about the next release and plan what should definitely go in there. Sometimes it turns out that a release can be made rather soon.What do you think? Does a release at this stage make sense?
Checklist
[x] I've read CONTRIBUTING.md
~I tested my configuration~
xmonad
version XXX (commit XXX if using git)~xmonad-contrib
version XXX (commit XXX if using git)~