It looks like there will a pre-release of 7.0 soon, and right now, the release notes page (https://github.com/apple/foundationdb/blob/master/documentation/sphinx/source/release-notes.rst) doesn’t seem to mention any change to the C API.
Will this be true for the entire 7.0 release? If yes, does this mean that there will be no real need to change API level from 620 to 700, on the application side? Or will there still be changes that will be selected depending on 620 or 700?
I think this PR that adds the ability to get a size estimate for a range is likely to make it in:
I think this issue to change a type to not be void* will be done too, though hopefully there won’t be any need to version it:
We also have a transaction option (include_port_in_address) that is documented as being the default behavior in version 700, with the option itself becoming deprecated.
It’s possible there will be other changes in the C API, though I can’t think of any at the moment.
The option change would be switchable by the API version, and if you plan to access the new range size API it would be best to specify 700 as your API version. I think it may technically still be possible to access the new API from old versions, though.
I like the fdb_transaction_get_estimated_range_size_bytes API 
Yes I remember seeing this comment in the options now. I think I will add a method in the binding that return the ports, and set the transaction option for 620, does nothing for 700+ and throws for < 620.
This should be transparent hopefully for most binding.
Should wrappers of the C 6.2 API work with the server in master now?* I’m seeing 100% of transactions timing out, and the transactions aren’t showing up in fdbcli. There might be something else going on, but this is one of my first guesses.
/* Specifically https://github.com/Clikengo/foundationdb-rs 0.4.1 and fdbserver at bfcdf6bc88856647425efc0b3f184f2c44cd8d89
Version 6.2 is protocol incompatible with master, so you won’t be able to use a 6.2 client library with it. If you want to connect to a cluster based on the master branch, you would also need to build a client library from the master branch and use that.
I’m linking against a client library built from master, but the wrapper is based on 6.2, if that makes any sense.
Bindings written against 6.2 will work with any future released client library.
I will assume that you’re running into the issue that a 6.2 client library can only talk to a 6.2 server, and a client library built from master should only be used with an fdbserver built from the same version of master.
fdbcli does not use the multi version client library, so if fdbcli works, it would sound like your bindings are picking up a mismatching client library version from somewhere other than what you built.
It should be fine to run client code against an old API version like 620, and in fact I’ve been running some of my own tests today that do exactly that. One thing to check is the trace logs for the server and/or the client. I believe if you have an incompatibility, you would see events like ConnectionRejected with a reason IncompatibleProtocolVersion, and possibly also IncompatibleConnectionClosed.
If you don’t see either of those, then the trace logs might provide other clues if there’s some problem establishing a connection to the cluster.
Thanks! Looking for ConnectionRejected helped me track down the incompatibility problem.