Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Ensure you are running the lowest support version of Erlang locally. As of CouchDB 2.2.0, this is a v17.x release. If you run with too new a version of Erlang, you may end up building a release asset that is unbuildable on older Erlang VMs (because the shipped rebar binary will be incompatible).

  • Checkout the code locally and run a clean build and test:

    Code Block
    # If you don't have CouchDB downloaded yet:
    $ git clone && cd couchdb
    # or, if you already have CouchDB cloned:
    $ cd couchdb && git pull && git checkout master && git reset --hard && git clean -ffdx
    # Then:
    $ ./configure && make check

  • Verify that any sub-repositories (fauxton, docs, etc.) have had their dependency versions updated in the top-level rebar.config.script file.
    • You may need to consult with the committers of changes to each sub-repo if these changes are ready to be incorporated into the next release build.
    • If necessary, bump the dependency specification, commit the change, and rebuild and re-run the tests as above.
  • Identify issues that should be resolved before cutting a release:
    • Check the last few Travis CI and Jenkins runs (master or release branch only) for any failed builds.
      • Any test failures should be logged as issues in GitHub issues.
      • Issues with the CI environment should not be considered release blocking, but should be resolved in a timely fashion.
    • Check for any open issues that appear critical or high priority, especially those tagged with the security label in GitHub.
    • Create a milestone in GitHub Issues, "x.x.x", representing the proposed version number for the release.
    • Mark all of the issues found above with the newly created milestone "x.x.x".
  • Ensure that the right version number is referenced in the code. As of 2.1.1 (2017-10), the version number is stored in two places: and rel/reltool.config.
  • Work with the development team to resolve these issues before proceeding. If changes are necessary, you are encouraged to issue pull requests and get the changes merged.
  • If possible, check that the automated package builds are valid. The Jenkins-built packages are available on . Or, you can packages are valid. Check the last full CI run in jenkins or build them yourself on a Linux machine with Docker installed:

    Code Block
    $ git clone
    $ git clone && cd couchdb && ./configure && make dist
    $ cd ../couchdb-pkg
    $ ./ ../couchdb/apache-couchdb-*.tar.gz