- More serious: why was Win32 major bumped from 2.10 to 2.12?
- this breaks foundation, hence current Stackage Nightly is kind of
broken for Windows now:
We needed to bump Win32 as per a request from the maintainer made at
Bumping it from 2.10.0 to 220.127.116.11 ran into
https://github.com/haskell/win32/issues/174, which was fixed by
Given this, our options at the time were:
1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32
2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10,
which is what caused WinIO/#174
3) Use Win32 18.104.22.168, which contains the requested fix(ghc/#20017), as
well as the explicit exports added by #175, along with a few other minor
changes from Win32 2.11 which I don't think are responsible for any of
the pain discussed in the stackage issue.
I made the decision to go with option 3 in the interests of getting the
However, if I understand correctly, we would still end up with the same
problems as brought up in the stackage issue if we went with option 1.
We might have avoided some of this pain if we went with option 2 and
reverted the offending commits from WinIO 2.10 instead of using explicit
import lists. But removing features from a major release of a library
didn't seem like a good idea at a time, and would have delayed the 9.0.2
release even more.
I hope this makes the reasoning for the decision clearer, and I
do apologise for any pain caused. I did believe that under the
circumstances bumping WinIO to 22.214.171.124 was the best way forward.
Perhaps option 2 would have been better in retrospect, but at the
time the benefits for such a change (in particular the regression in
functionality) in a major release of Win32 were not so clear.
Glasgow-haskell-users mailing list