Plan for v2

[mlms13]

Now that v1 is out the door, it's time to starting thinking about all the changes we might want for a v2. At a high level, the goal of a 2.0 release will be:

• Modernizing the stack
• Picking a preferred path (decoding into a result with a structured error type) and optimizing for that use case

So with those goals in mind, the roadmap:

Build/CI

• Switch to Melange for compilation
• Switch from npm to yarn
• Use Github Actions for CI
• Do way better at caching inside of CI
• Add a CI step to publish to npm

Library features

• Add letops support #127
• Delete all deprecated features #126
• Rethink custom/extensible validations #122
• Make ParseError's string-ification less confusing

Docs/website

• Migrate the website to Docusaurus 2
• Add a CI step to publish the website
• Add odoc comments #128
• Build docs in CI
• Embed odoc documentation in the website

[mlms13]

Progress is happening here: https://github.com/mlms13/bs-decode/tree/v2

I'll try to make pre-releases whenever especially notable changes happen.

[davesnx]

Hey @mlms13, I would like to use bs-decode and saw you wanted to migrate to Melange (and I might propose to push it to opam also)

Is there anything I can do to help?

[mlms13]

Hey @davesnx! I do still want to do all of those things, and there's even a branch going somewhere... It's been a few months since I actively made any progress there, though. This weekend I'll try to figure out how far I made it and see if there was anything in particular that I got stuck on. If so, I may reach out to you for help, either here or on Discord.

[mlms13]

...off the top of my head, I think there were some issues in my dune file that @johnhaley81 ran into (and may have found a solution for?) The dependencies will definitely all need to be bumped to the latest version of Melange, as well. They may currently be pinned to an older hash instead of a real release.

The other issue that I remember running into was general ecosystem versioning. Like, Relude hasn't quite been dune-ified yet (but I think that one was also getting close). And Relude depends on bs-bastet which has dune files but they're fairly old at this point, and not targeting melange.

I saw @Risto-Stevcev archived bastet, and I'd love to have a conversation about unarchiving and helping to maintain it, if that's something that would interest him. Otherwise we could consider a community fork.

Maybe the bigger question is how many of these things actually need to be "solved" in order to get bs-decode working with melange...

[davesnx]

Hey @mlms13,

Whatever makes more sense to you. I wouldn't rush to have a Melange compatible version when there's a lot of features you would like to pack, but packing more than your energy/patience might be an issue. Probably some adjustments make sense, but if the plan is v2 it make sense to contain a little bit of gardening.

One recommendation to unblock you is to vendor bastet for now and later you could rely on a published version of bastet. I have looked into @Risto-Stevcev and looks like he moved repositories in https://github.com/Risto-Stevcev/fossils which we might not look into GH notifications?

Regardless of the GH actions, odoc, documentation, let me know we have solved most of the issues for our repositories.

[Risto-Stevcev]

I haven't been coding in Ocaml for a long time now. I don't have the bandwidth to track how the ecosystem has changed or to maintain bastet anymore, feel free to fork it.

[mlms13]

@Risto-Stevcev sorry for the very delayed follow-up...

I've always loved the name Bastet. I don't mind forking, but I'd love to keep the Bastet name, to continue publishing to Opam using that name, etc. Also, with normal forks, it becomes difficult to figure out which is the "authoritative" fork where most of the development is happening.

So with all that in mind, how would you feel about:

1. Me creating an ocaml-bastet org on Github -- I'd be happy to make you a maintainer there as well
2. Transferring Risto-Stevcev/bastet to ocaml-bastet/bastet so that it preserves the original history of issues, pull requests, etc
3. Figuring out how to allow someone other than you to publish releases to Opam

[Risto-Stevcev]

Forking should preserve the original commit history as well. My views on transferring ownership of repos went from it's questionable to a definite no for me. The reason being that it presents a security risk to library users when the steward of the code shifts under their feet without them noticing. Devs using a library can and should always explicitly (not implicitly) transition to the new version of a library, especially if it's not from the same author(s) anymore. I think the same goes for companies that get bought by a new owner, which should include rebranding. So I think it's also probably not good to reuse branding either as it can make someone think it's from the same author(s).

[mlms13]

My views on transferring ownership of repos went from it's questionable to a definite no for me.

Wait, did you write this before the polyfill supply chain attack?! Impressive timing. 😁 Anyway, that's a totally respectable position to take. I think I'm going to end up re-implementing only the pieces I need, but I'll be sure to give a shoutout to Bastet, and I want to thank you for all the great work you put into it!

[Risto-Stevcev]

What's the polyfill supply chain attack? There was an npm package a few years back that was apparently really popular, was one of those that ended up as a dependency on a lot of packages. The dev that wrote it couldn't maintain it anymore and transferred the ownership, and the owner did something malicious with it. From what I remember it was a tiny library, it might've been a polyfill. Is that the same one you're referring to? The whole thing blew up on HN

[Risto-Stevcev]

Ah ok, it's this one right? https://news.ycombinator.com/item?id=40791829
That's literally the exact same thing that happened like a few years back, I forget the name of the library though