Dear Wiki user, You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.
The "Release_Procedure" page has been changed by NoahSlater: http://wiki.apache.org/couchdb/Release_Procedure?action=diff&rev1=141&rev2=142 <<TableOfContents(2)>> - = Checklist = + = PMC Resources = + + Grab a copy of the PMC resources: + + {{{ + git clone http://git-wip-us.apache.org/repos/asf/couchdb-pmc.git + }}} + + Change in to the PMC resources directory: + + {{{ + cd couchdb-pmc + }}} + + The commands in this document assume this as a working directory. + + = Housekeeping = + + Run through the following items by hand: * Update the `README` file with important information. + * Update the `DEVELOPERS` file with important information. - * Update the `NEWS` and `CHANGES` files with important information. + * Update the `CHANGES` file with important information. + * Update the `NEWS` file with important information. - * Check the list of recent releases and make sure each one has an entry. - * Check for "version has not been released" warnings. - * If this appears in the section for this release, remove the warning. - * If this appears in a section for an unreleased version, remove the section entirely. - * It is ''very important'' that these files are properly maintained. - * Add note about breaking changes to the `NEWS` file if necessary. + * Add note about breaking changes to the `NEWS` file if necessary. - * If working on a branch, make sure `NEWS` and `CHANGES` are synced with master. * Update the `acinclude.m4.in` file with version information. * LOCAL_VERSION_MAJOR should be the X in X.Y.Y * LOCAL_VERSION_MINOR should be the X in Y.X.Y * LOCAL_VERSION_REVISION should be the X in Y.Y.X - * LOCAL_VERSION_STAGE must always be empty on a release tag. + * LOCAL_VERSION_STAGE must always be empty on a release branch. - * When this is set, it indicates a development version. It is set on branches or on master so that the release number includes the source code revision number, which can be useful for development builds. * Update `share/doc/src/conf.py` with current year. * Update the [[Breaking_changes]] document. + Build a list of CVE numbers: + + {{{ + ./release/build_cve_list.sh + }}} + + This will produce output that ends with something like this: + + {{{ + Adding /home/apmail/private-arch/security/200502.gz (compressed) + Adding /home/apmail/private-arch/security/200410.gz (compressed) + Adding /home/apmail/private-arch/security/201005.gz (compressed) + Finding CVE numbers... + CVE-2010-0009 + CVE-2010-2234 + CVE-2010-3854 + CVE-2012-5641 + CVE-2012-5649 + CVE-2012-5650 + Writing CVE numbers... + /tmp/build_cve_list.sh.9PhpoO/cve_list.txt + }}} + + This runs commands on `people.apache.org` on your behalf. You must read and understand the source before running it. + + Check the documentation: + + {{{ + ./release/check_docs.sh CVE_LIST_FILE + }}} + + Replace ''CVE_LIST_FILE'' with the file generated by the `build_cve_list.sh` script. + + So, in this instance, you would run: + + {{{ + ./release/check_docs.sh /tmp/build_cve_list.sh.9PhpoO/cve_list.txt + }}} + + This is going to check several things for you. + + There will be two sections that look like: + + {{{ + Checking CVEs in NEWS... + }}} + + These sections should be empty. + + If you see any output here, it means a CVE is missing from a `NEWS` or `CHANGES `file. + + You should expect to see output here for an undisclosed CVE. + + There will be several sections that look like: + + {{{ + Comparing NEWS, 0.8.x to 0.9.x... + }}} + + These sections should be empty. + + If you see any output here, it means some entries in a `NEWS` or `CHANGES` file are missing in a later version. + + Information in the `NEWS` or `CHANGES` files should always be merged forward between branches. + + There will be several sections that look like: + + {{{ + Scanning 0.8.x... + }}} + + These sections should be empty. + + Occasionally, you will see output that looks like: + + {{{ + # This version has not been released yet. + }}} + + This is fine, and indicates that there are unreleased changes on the branch. + + It must not appear on the branch you are about to release. + + If this script generates any errors, you should fix them. + + While working on the fix, you may find that you need to run the script repeatedly. + + When it first runs, you will see something like this: + + {{{ + Creating temporary directory... + /tmp/check_docs.sh.9oNHt9 + }}} + + You can copy that directory name and append it the command to re-use the cached data: + + {{{ + ./release/check_docs.sh CVE_LIST_FILE TMP_DIR + }}} + + Replace ''CVE_LIST_FILE'' with the file generated by the `build_cve_list.sh` script. + + Replace ''TMP_DIR'' with the directory created by the previous invocation of the `check_docs.sh` script. + + So, in this instance, you would run: + + {{{ + ./release/check_docs.sh /tmp/build_cve_list.sh.9PhpoO/cve_list.txt /tmp/check_docs.sh.9oNHt9 + }}} + + This will be significantly faster than running the script from scratch again. + = Preparing the Community = - Submit an RFC to the [email protected] mailing list asking for a request for comments on the release. + Start a "[DISCUSS]" thread on the [email protected] mailing list, asking for comments on the release. - Ask all developers to specifically check the `NEWS` and `CHANGES` file for anything that has been added in this release. + Ask that pecheck the `NEWS` and `CHANGES` file for anything that has been added in this release. = Preparing the Release =
