Would be nice to push a 0.10.10.1 release

[vdukhovni]

With #204 fixing a significant builder bug (infinite loop), and fixing all the GHC 7.4+ CI issues, without introducing any new issues, I feel it is time for a new release. I'll open a PR that adds updates the package version and adds an entry to the changelog.

[cartazio]

sounds good to me
@dcoutts you still wearing maintainer hat atm or is it in hvr and CLC's lap?

@hvr ignoring maintainership leadership stuff, do you have any thoughts about cutting a release with this bug fix?

[cartazio]

hvr has indicated he will line things up so that we release when the next ghc lands (7.10.2 or 7.12.1). so if theres any other low hanging / obvious bugs etc to address, lets do it !

[bgamari]

@hvr, what can we do to move this forward?

[vdukhovni]

@hvr, what can we do to move this forward?

[ Probably some coördination between you and @hvr :-) ] There are likely a few more PRs that should be merged, e.g. #133... Is anyone keeping a list?

I am testing #191, which would perhaps be nice to have in GHC 8.12, but is at best a noop in earlier releases. Should that make the cut? It may need to tweak unsafeFinalize just in case there's some version of base in which finalizing things that couldn't need finalizing throws an error, though perhaps that won't be the case? If we leave it out, it may be a while before the next opportunity to release an updated bytestring...

It almost feels like bytestring should be in base instead, it could perhaps make it easier to keep it in sync with the evolving compiler releases.

[vdukhovni]

It almost feels like bytestring should be in base instead, it could perhaps make it easier to keep it in sync with the evolving compiler releases.

For example, while bytestring itself still supports GHC 7.x, a version included in base with GHC 8.X (for some x >= 12) need not, and could merge #174

Of course if bytestring is merged into base, it would have to become an empty shell exporting no modules (or just some dummy module) if the version of base is high enough...

[bgamari]

Let's first focus on the critical bug-fixes. #133 and #204 are really the only two open MRs that are truly necessary as far as I can tell. These would be enough for a minor release which could be shipped with 8.8.4 and 8.10.2. For 8.12.1 we might want more, but I would rather get the stable branches sorted before worrying about this.

[vdukhovni]

Let's first focus on the critical bug-fixes. #133 and #204 are really the only two open MRs that are truly necessary as far as I can tell. These would be enough for a minor release which could be shipped with 8.8.4 and 8.10.2. For 8.12.1 we might want more, but I would rather get the stable branches sorted before worrying about this.

Fair enough. I'd be tempted to fold in at least #223 (CI fix) and #225 (doc fix), because zero risk.

[bgamari]

@dcoutts, @hvr, @sjakobi, @cartazio, is there anything holding us back on this? At this point 8.8.4, 8.10.2 are both blocked on this and have been for weeks now.

[sjakobi]

@bgamari master seems to be in a pretty good state. I think a release would be a matter of bumping the version number, uploading it to Hackage and pushing a Git tag.

I can do that if I get the necessary permissions.

[vdukhovni]

We should merge #223, #225 and #227

[vdukhovni]

And IIRC @bgamari wanted to see #133 merged, since unaligned writes are a potential problem?

[sjakobi]

@chessai (as the current CLC chair) has given commit bits to @bgamari, @hsyl20 and me, so we can prepare a release.

The most important outstanding PR for this bugfix release seems to be #133 (#232 is a rebased version).

@hsyl20, would you like to review #133 too?

I'd currently prefer not to include #227 to avoid having a potential CI hiccup interfere with a speedy release process.

[vdukhovni]

I'd currently prefer not to include #227 to avoid having a potential CI hiccup interfere with a speedy release process.

I'll rebase #227, with a goal of demonstrating that CI continues to work... If anything, it makes CI more robust.

[vdukhovni]

CI for #227 is all green: https://travis-ci.org/github/haskell/bytestring/builds/701855179

[bgamari]

Indeed it would be good to get this done so we can move ahead with 8.10.2 and 8.8.4.

[sjakobi]

I'm preparing a release in #235. Reviews are welcome! :)

@vdukhovni FWIW, I do want to merge #227 very soon. It just didn't seem necessary for this release.

[sjakobi]

v0.10.10.1 is on Hackage now: https://hackage.haskell.org/package/bytestring-0.10.10.1

You'll surely notice the little bug in the changelog:

0.10.10.1 – June 2020

The release includes a fix for a different off-by-one error though, so I guess it cancels out! 😄

[sjakobi]

I forgot the most important bit:

Many thanks to everyone who contributed to this release! I really appreciate it! :)