...
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".
- Check the last few Travis CI and Jenkins runs (master or release branch only) for any failed builds.
- 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
andrel/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
...
Code Block |
---|
export GPG_ARGS="--default-key=DEADBEAFDEADBEEF" |
Code Block |
---|
gpg --list-keys |
...
- 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 therebar.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 thegit clean
andgit reset
commands. 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#" $ git push origin --tags
Build the release candidate tarball (substitute the correct number for the
#
below):Code Block language bash $ cd couchdb $ git checkout x.x.x-RC# $ git reset --hard && git clean -ffdx $ COUCH_RC=# make rcdist
Checking the Candidate
This wiki has separate instructions on testing a release candidate.
...