Release Number

See for how to keep track with version you’re using.

There are not objective criteria to distinguish a major version and a minor version. All features and improvements can go to minor versions, and they are applicable to new options, option default changes or public API change if needed.

A major version is usually made when several major features or improvements become stable.

Compatibility Between Releases

See RocksDB Compatibility Between Different Releases.

Release Frequency

RocksDB has time-based periodic releases. We typically try to make a minor release once every month.

Release Branching and Tagging

  • When we release, we cut-off the branch from master. For example, release 3.0 will have a branch 3.0.fb. Once the branch is stable enough (bug fixes go to both master and the branch), we create a release tag with a name ‘v3.0.0’. While we develop version 3.1 in master branch, we maintain ‘3.0.fb’ branch and push bug fixes there. We release 3.0.1, 3.0.2, etc. as tags on a ‘3.0.fb’ branch with names ‘v3.0.X’. Once we release 3.1, we stop maintaining ‘3.0.fb’ branch. We don’t have a concept of long term supported releases.

Here is an example:

For example, a bug is fixed in master that needs to be backported to 3.1. Here is the order:

  2.      |                     |                                     |  
  5.      |                                                           V
  7.           3.1.0        3.1.1       3.1.2                              3.1.3

Before an official release, release branch is used within Facebook servers for two weeks or more. We encourage other people to try out release branches before they are officially released too. When an official release is made, you can assume that it has been stably running in production for two weeks.

Maven Release

(Under construction)