Prepare release 0.11.0.0

[Bodigrim]

I think we are good to go, but will wait until the next week to upload.
It would be nice to include #258 as well, if it is ready in time.

CC @vdukhovni @fumieval

[sjakobi]

Wow, that's a lot of goodies merged in a short time! 👍

[vdukhovni]

@archaephyrryx has found a substantial performance bug in findIndices #269 . The fix is being tested now, and will shortly be a PR. I'd very much like to see the fix merged shortly. The bug, for example, degrades the throughput of lineSplit in streaming-bytestring by ~20x-30x. Please don't release 0.11 just yet...

[Bodigrim]

@vdukhovni no problem, especially if it gets merged this week.

[andrewthad]

I like your rewording of the changelog entry for the change involving strlen.

[fumieval]

Seems fine to me

[sjakobi]

Should the changelog mention #284?

[vdukhovni]

Should the changelog mention #284?

Though the affected users are the poor sods who might try to use an older bytestring with GHC 9.0, I think this is a good thing to note in the change log, which some might find more easily than the commit or another source.

[Bodigrim]

Updated again.
I would like to merge this on Thursday, tag as 0.11.0.0-rc1 and gather feedback over the weekend before proceeding to a release.

[vdukhovni]

Updated again.
I would like to merge this on Thursday, tag as 0.11.0.0-rc1 and gather feedback over the weekend before proceeding to a release.

Looks good. Speaking of the deprecation change: asking users to use Data.ByteString.Internal.accursedUnutterablePerformIO instead of Data.ByteString.Internal.inlinePerformIO. Is there still reason to use the former rather than the unsafeDupablePerformIO in base? They both ultimately have the same effect, and I did not find noticeable performance differences between them... Do we still need Data.ByteString.Internal.accursedUnutterablePerformIO (for reasons other than backwards compatibility)? It too could be deprecated and removed in a later major release if unsafeDupablePerformIO works just as well.

[Bodigrim]

@vdukhovni AFAIU it is mostly a matter of compatibility with base < 4.4, which do not provide unsafeDupablePerformIO.

[vdukhovni]

@vdukhovni AFAIU it is mostly a matter of compatibility with base < 4.4, which do not provide unsafeDupablePerformIO.

Sounds plausible... If that's the case, we can deprecate accursedUnutterable... as soon as we drop support for GHC 7.0. Base 4.4 is GHC 7.2, dating back to Aug 2011, and 7.0 is from Nov 2010. So by this time next year, 7.2 will be a decade old.

I'd actually be tempted to do the deprecation of accursedUnatterable... now, any remaining 7.0 users can ignore the warning. We can then remove it in 0.12.

[Bodigrim]

I do not want to deprecate it in a hurry, and it is really a high time for release.