Release Planning: unix-2.8.0.0 (GHC 9.6.x)

[emilypi]

TODO:

Baud Rate

• Implement BaudRate with PatternSynonyms. #145
• Support other baud rates #74

blockSize/blockCount

• Add missing blockSize and blockCount accessors to System.Posix.Files. #123
• Add accessors for st_blocks and st_blksize #78

Doc fixes

• Requires an audit

[hs-viktor]

Is this a request to review the 4 PRs?

[Bodigrim]

Reviews would be nice.
(It's a meta-ticket with everyone in assignees)

[hs-viktor]

I've looked some of these over. Not sure what's next. For the Baud rates I really would like to see PatternSynonyms, and support for ad-hoc user-specified code points. For the stat structures, returning Nothing when not supported makes sense to me, and when the associated data types are not defined in base, I'd suggest to just define them to Int, but since we'll always return Nothing, any integral type is as good as any other.

[Bodigrim]

PatternSynonyms in #145 require GHC 8.0. Is everyone on board with dropping support for GHC < 8.0? I'm fine with it for unix-2.8 series.

[hs-viktor]

Don't know about everyone, but I'm definitely on-board.

[hvr]

I'm generally not on board with dropping support for old GHCs unless it is not possible to support those anymore.

As you can see in https://matrix.hackage.haskell.org/package/unix I've made sure that we kept support back till GHC 7.4.2

[Bodigrim]

@hvr what's the reason to support GHC < 8.0 in 2020? When will you be ready to abandon it?

[hs-viktor]

I'm generally not on board with dropping support for old GHCs unless it is not possible to support those anymore.

As you can see in https://matrix.hackage.haskell.org/package/unix I've made sure that we kept support back till GHC 7.4.2

I'm sympathetic to this on general principles, but find that managing system interfaces portably without PatternSynonyms is just too painful. One ends up locked into rigid algebraic datatypes that map poorly onto a platform-dependent and time-dependent set of constants, and require unnecessary conversions between the underlying numeric values and the supported enums.

So for me GHC system programming really only becomes manageable with GHC 8.0. :-(

[ EDIT: And as I mentioned elsewhere, only GHC 8.8 and 8.10 are still getting bug fixes, thus e.g. the MVar crash I ran into will not be fixed in 7.8, 7.10 or 8.0–8.6. To me that strongly signals that new releases of libraries do not need to target old GHC releases once doing so holds back doing new things "the right way". ]

[hs-viktor]

The release date of GHC 7.10.3a (last tagged 7.10.x release) will soon be 5 years in the past:

commit 9b50b5a5da4325e703210b2de2d816debe4c8a64 (tag: ghc-7.10.3a-release)
Author: Ben Gamari <bgamari.foss@gmail.com>
Date:   Tue Dec 8 19:47:57 2015 +0100

And 7.10.1 was released in March of the same year:

commit ca00def1d7093d6b5b2a937ddfc8a01c152038eb (tag: ghc-7.10.1-release)
Author: Austin Seipp <austin@well-typed.com>
Date:   Wed Mar 25 17:33:07 2015 -0500

The 8.0 release has now been out for more than 4 years:

commit 4986837f8168cacf95c24fecc84d7b36c47f3c11 (tag: ghc-8.0.1-release)
Author: Ben Gamari <bgamari.foss@gmail.com>
Date:   Tue May 17 18:05:24 2016 +0200

And the 7.x releases can continue to be used with unix-2.7. Setting the floor for unix-2.8 to GHC 8.0 does not break these older GHC versions. So I think it is safe and reasonable to move on.

[Bodigrim]

What is the recommended way to run unix tests, being outside of GHC source tree?

[Bodigrim]

Let's try an easier question :)
Has anyone ever run the tests outside of GHC source tree?