plan to new release version?

[darren-fu]

is there a plan to release new version and publish to crates.io?

[exabytes18]

+1.

For reference, the slow release cadence is annoying for organizations who wish to publish crates that depend on rust-rocksdb and want to use any of the improvements in the past 9-month (time since last release). This stems from the fact that crate registries typically don't allow publishing crates with a git dependencies, meaning crates are restricted to only referencing up to the latest published version (0.21.0), which is getting pretty old at this point. Alternatively, those who need to publish their own crate which depends on newer unreleased features of rust-rocksdb can publish a shadow copy of rust-rocksdb crate under a different name, but that's very clunky.

My ask would be: could the rust-rocksdb maintainers publish releases more regularly?

[girlbossceo]

There has even been fixes relating to database corruption. This should have certainly prompted a release. There was another maintainer added to the project, why is there a lack of interest in publishing new releases?

https://github.com/facebook/rocksdb/releases/tag/v8.5.3

Please note 8.5.1 includes a fix for a persisted database corruption in an unlikely edge case. Upgrading to a version including this fix, like this one, is highly recommended!

https://github.com/facebook/rocksdb/releases/tag/v8.6.7

Added enhanced data integrity checking on SST files with new format_version=6. Performance impact is very small or negligible. Previously if SST data was misplaced or re-arranged by the storage layer, it could pass block checksum with higher than 1 in 4 billion probability. With format_version=6, block checksums depend on what file they are in and location within the file. This way, misplaced SST data is no more likely to pass checksum verification than randomly corrupted data. Also in format_version=6, SST footers are checksum-protected.

[zaidoon1]

There was another maintainer added to the project, why is there a lack of interest in publishing new releases?

I have requested access to publish crates but I still don't have it, I'm hoping once/if I get access, I can do more regular releases. However, we still need more mainters as both aleksuss and stanislav-tkach don't have enough time to maintain this repo and we ideally need at least two active mainters so we can review prs, etc.. If more people apply and get granted access to maintain, the situation will improve.

@niklasf was interested to become a maintainer at some point (#750). If you are still interested maybe we can push to get you approved?

[aleksuss]

@zaidoon1 I guess you can prepare the release PRs. I will publish it.

[girlbossceo]

Are we able to track the progress of actually making a new release? Can we help in any way possible to get a release going?

• RocksDB has had fixes relating to database corruption and recommend people to use the latest version (see my comment above)
• The bindgen build dependency in the latest rust-rocksdb stable has a vulnerability ([security] cargo audit found vulnerabilities #858). Even if it does or doesn't affect rust-rocksdb, it is always going to be reported as a vulnerability in rust-rocksdb and fail cargo audit which doesn't look good.
• The earliest date of asking for a new release is on 15 July 2023 which users report that they cannot build with GCC 13 as a toolchain which is fixed in the latest RocksDB version (New release with the latest rocksdb version #804)
• Another Rust project, SurrealDB, in the above issue hasn't been able to update RocksDB because rust-rocksdb has not cut a new release (Feature: Rocks db upgrade surrealdb/surrealdb#2264 (comment))
• My Rust project has been using the git rust-rocksdb as a hacky workaround for the lack of a new release, but this is not ideal and I had to drop this due to issues that don't appear present in the latest rust-rocksdb stable.
• Undefined behaviour was fixed in October 2023 but no release was made (Raw iterator segfaults when user forgets to seek before calling next #824) (fix: add raw iterator validation before calling next method #829)

What is the actual true blocker here for a new release besides "more maintainers"?

@zaidoon1 said they've wanted to make a new release but are pending permissions. @aleksuss said an upcoming release is happening (#858 (comment)).

There has to be some other issue that's not being told here. What can we do to help? A new release with the latest RocksDB is all that's really being asked here, and in the future more frequent releases when RocksDB is updated, nothing else.

[zaidoon1]

As I've said, I don't have permission to publish new versions and my requirements for my projects have changed to require me to have the latest dependencies/rust versions/rocksdb version so I have forked this repo: https://github.com/zaidoon1/rust-rocksdb and now maintain my own version that uses the latest version of rust/rocksdb/dependencies and have published this.

My fork will continue to follow this repo in the sense that any new features added to this repo will be added to my fork and I will try my best to review prs in this repo to keep things moving, however, as I've said, I don't have permissions to publish and this repo requires at least another approval to merge any pr (or wait 2 weeks per the wiki). Given that other maintainers are not actively maintaining this repo (understanbly since they are busy with other things), this repo will not have fast releases unless more active maintainers are added/given permission to publish.

If my fork suits your need, feel free to use it and I welcome an prs to improve things.