Page History

...

• Ensure you are running the lowest support version of Erlang locally. 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).

• Do not use MacOS later than Ventura. Tar files built there will have random attestation xattr attributes and hidden files added.

• 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 # To also test nouveau, make sure to have at least a JDK version >= 11 available and use $ ./configure --with-nouveau && make check # To test using the new QuickJS Javascript engine as a default use $ ./configure --js-engine=quickjs && make check # It's possible to combine multiple options and check nouveau and QuickJS $ ./configure --with-nouveau --js-engine=quickjs && 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. That version is stored in version.mk
• 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 --with-nouveau && make dist $ cd ../couchdb-pkg $ ./make-releases.sh ../couchdb/apache-couchdb-*.tar.gz

  
  

...