search

mlms13 / bs-decode

Type-safe JSON decoding for ReasonML and OCaml
https://mlms13.github.io/bs-decode/docs/what-and-why
MIT License
103 stars 18 forks source link

Plan for v2 #116

Open mlms13 opened 1 year ago

mlms13 commented 1 year ago

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:

So with those goals in mind, the roadmap:

Build/CI

Library features

Docs/website

mlms13 commented 1 year ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

...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 commented 9 months ago

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 commented 9 months ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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