You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking at changes to http_sfv, and noticed that this library depends upon it.
See a summary of how it would work. Basically, it's moving from an object-based approach to a set of functions that produce datastructures. This should be more performant and I think more straightforward to use.
I'm writing here to ask:
If you have any thoughts / preferences about the API.
If the new API is merged, how you'd like to manage the dependency. I'd probably version it as 0.10.1, FWIW.
The text was updated successfully, but these errors were encountered:
Hi - this seems fine, I don't have any strong preferences one way or another. I have a vague idea that an object-oriented API might make it easier to type hint the interfaces appropriately, but I'm not sure if that's a good reason to stay with that approach.
To manage the dependency, I imagine I'd start by publishing a release to this package to depend on http-sfv >= 0.9.8, < 0.10. Then once you publish your update I will do a release that updates the API and depends on http-sfv >= 0.10.1. Does that sound right? If so, I can push an update in the next day or two.
Hi,
I'm looking at changes to
http_sfv
, and noticed that this library depends upon it.See a summary of how it would work. Basically, it's moving from an object-based approach to a set of functions that produce datastructures. This should be more performant and I think more straightforward to use.
I'm writing here to ask:
0.10.1
, FWIW.The text was updated successfully, but these errors were encountered: