Have you thought on how to fix the redistribution part of the fdb_c binaries alongside the binding? I’m faced with similar issues with the .NET binding, and I’m still unsure on what is the best solution.
One possibility would be to have the “core” binding available has a package versioned to follow the FoundationDB new APIs, and then have another “binary” package that redistributes some version of the fdb_c client, plus a dependency to the core binding package. But I’m not sure on what minimum/maximum version range should tie both packages together:
- You can use an older version of the core binding with a more recent
fdb_cversion (tied to the version of your cluster and for db bugfix) - You can also use a newer version of the core biding (bugfixes, some changes related to the underlying node.js or .NET CLR version, etc…) and rely on
setAPIVersion(..)to protect your app against unwanted behavior changes.
One solution is of course to have both packages independent from each other, but this does seem a bit of a bummer to not have a single “end point” to have a fully working solution for local development that just works out of the box.