I maintain the nodejs bindings for foundationdb. Because the nodejs bindings are maintained and published out-of-tree, there’s a decoupling between which version of the node bindings people are using and which version of the foundationdb database people are using. So versioning is tricky. There are 4 different version numbers in play:
- The version of the foundationdb database (server and client). Eg 6.2.15
- The version of the nodejs foundationdb library. Eg 1.1.2.
- The ‘runtime API version’ the client selects
- The ‘header API version’ which node-foundationdb is compiled against
Every time I come back to this, I’m always confused about how those numbers all interact. For example, the foundationdb library sets the C “header version” via FDB_API_VERSION. How is this related to the application version?
Looks like runtime version <= header version, and header version <= libfdb_c.
We recently added support for API version 630 to the nodejs library, which included updating the header version (via
#define FDB_API_VERSION 630). Unfortunately, this has caused problems for users running older versions of foundationdb.
What header version should I be setting in the node foundationdb bindings?
- Tell users to match node-foundationdb with the version of the foundationdb database they have installed? This is unfortunate coupling. I don’t have the time or interest in maintaining a tableau of versions of the bindings for each version of the fdb API. Is there a chart anywhere showing which versions will work with which other versions? I’m happy to set a minimum supported fdb version for node-foundationdb, so long as its something reasonable.
fdb_select_api_version_impland force the issue? Would this cause weird issues?
- Be pessimistic with API versions, and just wait 6 months - 1 year before supporting new API features in node-foundationdb, to maintain more compatibility with older database versions?