Page History

...

• 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 incomaptibleincompatible).

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

  Code Block
  language bash
  # If you don't have CouchDB downloaded yet: $ git clone https://github.com/apache/couchdb && cd couchdb # # or, if you already have CouchDB cloned: $ cd couchdb && git pull && git checkout master && git reset --hard && git clean -ffdx # # Then: $ ./configure -c && 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: version.mk 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 https://repo-nightly.couchdb.org/ . Or, you can build them yourself on a Linux machine with Docker installed:

  Code Block
  language bash
  $ git clone https://github.com/apache/couchdb-pkg $ git clone https://github.com/apache/couchdb && cd couchdb && ./configure -c && make dist $ cd ../couchdb-pkg $ ./make-releases.sh ../couchdb/apache-couchdb-*.tar.gz

  
  

...

• Confirm that no one else is building the RC at the same time as you are. 
• Update your local git clone to the latest version of the code.
• Check the rebar.config.script file and look at all of the dependency version numbers. If any are raw git hashes (not x.x.x-style version numbers), tag those sub-repositories first. Then, update the rebar.config.script with these version numbers and commit the change. No dependencies should be referenced by a raw git hash.
• Run one final make check as in the first section of this process, being sure to run the git clean and git reset commands.
  

• If this is the first RC for a new major or minor release (3.0.0, 2.3.0, etc. but not 2.3.1) then create a branch:

  Code Block
  language bash
  $ git checkout -b #.#.x git push origin

  
  

• Tag this version with x.x.x-RC# where # represents which release candidate this is (1, 2, 3...):

  Code Block
  language bash
  $ git tag -a x.x.x-RC# -m "Version x.x.x-RC#" --sign $ git push origin --tags

   

• Build the release candidate tarball (substitute the correct number for the # below):

  Code Block
  language bash
  $ cd couchdb $ git reset --hard && git clean -ffdx $ ./configure -c $ make dist

  
  

Checking the Candidate

...