0.12.0.0 release planning

[clyring]

From #569 (comment) :

It's tangential, but I suggest 0.11.4.0 to be the last release in 0.11 series. Backporting got pretty challenging recently. Shipping bytestring-0.12 with GHC 9.8 late 2023, three years after bytestring-0.11 seems a decent support period for a major branch to me.

@Bodigrim Can you elaborate on what challenges you faced recently with backporting? (I imagine 3b0f5d3 could have been a bit painful depending on how you approached it, but that seems a bit exceptional.)

Three years sounds like a good amount of time between major releases to me, though I'm not optimistic about getting bytestring-0.12 shipped with ghc-9.8. "Late 2023" is not far off; we should start thinking now about what outstanding issues/tasks deserve attention before then.

My preference is to make the last planned release in the 0.11 series concurrently with the first release of the next major version; that makes good signalling easy and I think we can do so at very low cost. That would likely make 0.11.5.0 the last 0.11-series release.

[Bodigrim]

@Bodigrim Can you elaborate on what challenges you faced recently with backporting?

It's mostly import lists diverging, which makes backports annoying.

"Late 2023" is not far off; we should start thinking now about what outstanding issues/tasks deserve attention before then.

We don't necessarily need to deliver something revolutionary. Just getting released what's already done (https://github.com/haskell/bytestring/milestone/5?closed=1) would be enough.

Finally fixing #13 (or deciding not to fix) is a nice to have.

It's probably time to act on #249.

Dunno what to do with #140. My tinkering in #521 was not quite successful.

My preference is to make the last planned release in the 0.11 series concurrently with the first release of the next major version; that makes good signalling easy and I think we can do so at very low cost.

There is very little value in bytestring releases, which are not wired into GHC. However, we might need to release something for GHC 9.6.X, which could be 0.11.5.0, so you are probably right.

[clyring]

The ghc-9.8 branch is supposed to be cut in a few days. I propose we should cut a bytestring-0.12 branch and bump ghc's bytestring submodule at about the same time. In light of that:

• Let's punt on the trickier issues getLine doesn't honor handle's newline setting #13 and Surprising behavior of ByteString literals via IsString #140 for now. (We will certainly be able to make more progress on the latter when deprecating instances becomes possible.)
• I'd like to resolve Rewrite rules for Lazy.compareLength are too lazy #507; this means either a trivial patch or a wontfix label and some documentation.
• I'll see about bringing the changelog up-to-date very soon.

[Bodigrim]

I definitely want bytestring-0.11.5.0 to be cut to deliver #582: this was a production issue, and migration of the ecosystem to bytestring-0.12 would take lots of time.

#249 is simple enough to include.

[Bodigrim]

JavaScript backend of GHC requires either pure Haskell implementation or JS shims for all cbits. I don't have energy to work on this myself, but if @hsyl20 and team are interested to contribute this soon, we might want to delay our release cycle.

CC @doyougnu @chreekat @JoshMeredith

[hsyl20]

If someone wants to volunteer, I've started implementing Haskell versions of the C functions 1 year ago: https://github.com/hsyl20/bytestring/commits/hsyl20/pure-bytestring

Perhaps we could do this incrementally:

1. add a Cabal flag "haskell-only"/"native"/whatever to enable Haskell functions instead of C ones when possible.
2. add CI job with this flag enabled
3. Optional: automatically enable this flag when arch(javascript) (is that possible with Cabal?)
4. incrementally add Haskell functions corresponding to the C ones

Would this process be accepted? It would be simpler than to prepare a single huge MR.

[hsyl20]

3. Optional: automatically enable this flag when `arch(javascript)` (is that possible with Cabal?)

Answering myself: the Cabal flag would just enable a CPP flag so we can also enable the CPP flag if arch(javascript).

[chreekat]

I have a couple of novice questions:

1. What did GHCJS do?
2. What's the feasibility of just teaching Cabal to chuck c-sources at emscripten?

Otherwise, I'm afraid my experiments with GHC-JS were just hobby stuff, and now that Zurihac is over, I only have a couple hours a week to devote to it. :) Don't count on me to affect bytestring timelines in any meaningful way!

[doyougnu]

I have a couple of novice questions:

1. What did GHCJS do?
2. What's the feasibility of just teaching Cabal to chuck c-sources at emscripten?

Otherwise, I'm afraid my experiments with GHC-JS were just hobby stuff, and now that Zurihac is over, I only have a couple hours a week to devote to it. :) Don't count on me to affect bytestring timelines in any meaningful way!

GHCJS used a JS shim.

[hsyl20]

1. What did GHCJS do?

GHCJS maintained JS sources for packages in a "shims" library. E.g. for bytestring: https://github.com/ghcjs/ghcjs/blob/ghc-8.10/lib/boot/shims/pkg/bytestring.js.pp

We could port some of this code in bytestring but I'd rather maintain Haskell code than JS code.

2. What's the feasibility of just teaching Cabal to chuck c-sources at emscripten?

Moritz has been exploring this with a custom Setup.hs file that would build and link C sources with emscripten. But it's quite difficult because Emscripten assumes that the C memory is a single big JS array, which is not what the JS backend has. So we would have to generate some glue code derived from the C sources... At this point we might as well write a C to JS compiler ourselves that would generate the appropriate JS :)

Edit: or we could derive the glue code from some extended Haskell signature. That's what Moritz has started to implement: https://github.com/input-output-hk/plutus-apps/blob/f0e5fd6415f826ddbfbaae53f6db20a57779066e/js-bindgen/app/Main.hs

[Bodigrim]

Perhaps we could do this incrementally:
...
Would this process be accepted? It would be simpler than to prepare a single huge MR.

Makes sense to me, but since AFAIU you have more pressing matters at hand, let's target it for the next release, closer to the end of the year.

[Bodigrim]

@clyring I guess we are good to go with both bytestring-0.11.5.0 and bytestring-0.12.0.0. Do you have time to prepare releases or would you like me to step up?

[clyring]

I think everything is good-to-go. I will make both releases in a few hours.

[clyring]

The JS compatibility discussion can be continued at #625. 0.12.0.0 was released months ago; this ticket can be closed.