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 incompatible).

• 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 && 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 packages are valid. Check the last full CI run in jenkins or 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 --without-proper && 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 --without-proper $ make dist

  
  

Checking the Candidate

...

• First, build the binaries. On a Linux machine with Docker:

  Code Block
  language bash
  $ docker pull --all-tags couchdbdev $ git clone https://github.com/apache/couchdb-pkg && cd couchdb-pkg $ ./build.sh couch-all https://dist.apache.org/repos/dist/release/couchdb/source/#.#.#/apache-couchdb-#.#.#.tar.gz

  
  

• Double-check that the contents of the pkgs directory include the expected results:
  • couch/centos-6/x86_64 should contain the couchdb RPM as well as the SpiderMonkey 1.8.5 RPMs.
  • couch/centos-7/x86_64 should contain the couchdb RPM.
  • couch/debian-jessie|debian-stretch|ubuntu-trusty|ubuntu-xenial|ubuntu-bionic should each contain the appropriate couchdb deb.

• Now, upload the binaries to Bintray and publish them:

  Code Block
  $ BINTRAY_USER="your-userid-here" BINTRAY_API_KEY="your-key-here" ./build.sh couch-upload-all

  
  If this fails, or you want to do it the old labour intensive way, the old web-based approach is below:

  • Visit the appropriate repo: https://bintray.com/apache/couchdb-deb/CouchDB or https://bintray.com/apache/couchdb-rpm/CouchDB  
  • Click on the New Version link. The version number should be x.x.x, and the description should be "Version x.x.x".
  • Click on the breadcrumb of the version number to return to the view of the version itself, such as https://bintray.com/apache/couchdb-rpm/CouchDB/2.1.0.
  • Click on the Upload Files link.
  • For RPMs, specify the appropriate target path: /el6/x86_64 or /el7/x86_64 as appropriate.
  • For debs, specify the appropriate parameters: distribution name (jessie, trusty, xenial), component name main, architecture name amd64. All platforms can be done in one go.
  • Click to add and upload the package. (Bintray automatically generates sha256 checksums.)
  • Wait for the upload to finish, then click Save Changes for RPM. For Debian, repeat the last 2 steps for all the packages, then click Save Changes.
  • Visit the appropriate repo: https://bintray.com/apache/couchdb-deb/CouchDB or https://bintray.com/apache/couchdb-rpm/CouchDB
  • Click on the newly created version under the Versions heading, then click on Files to see the uploaded files. Confirm everything is as expected.
  • In the banner that appears, click Publish.
  • Note: this may not be necessary... Sign the Debian repository. You will need your Bintray API Key for this, which you can find under your account settings.

    
    

    Code Block
    language bash
    $ curl -X POST -u $BINTRAY-USER:$BINTRAY-API-KEY https://api.bintray.com/gpg/apache/couchdb-deb/CouchDB/versions/X.X.

    
    

...