Closed vitalyisaev2 closed 4 years ago
@vitalyisaev2 I have reverted #162 for now. Versioning to sync with upstream is a good idea, @jamesbibby how you handle this?
I suggest we open a branch for the new 6.2.4 release of RocksDB and make an effort to implement the full C api available at that point. From there we can try to have master reflect the latest versioned release and keep the README up to date. As for supporting prior releases, we could tag RocksDB versions so that people have a stable version to pull for a particular release (though we may not keep up with bug fixes on prior releases). Does that make sense?
The versioned release schedule for RocksDB is not really something we can control , however, I have opened a question in the dev group (on FB)
@tecbot @JelteF this is caused by #162
C API functions introducted by this MR are still not released after 5 months. I can't find them in the latest release: https://github.com/facebook/rocksdb/blob/v6.2.4/include/rocksdb/c.h (by the way, why does it take so long?)
Now
gorocksdb
can be only compiled with the master ofrocksdb
. This may decrease stability of the software that usesgorocksdb
. I think that we should look towardsgo.mod
and synchronize tags ingorocksdb
with the releases ofrocksdb
. At least, the README ofgorocksb
must notice that master ofrocksdb
is requried (5.16+
is misleading).