couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Release_Procedure" by NoahSlater
Date Sun, 03 Mar 2013 23:35:18 GMT
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 dev@couchdb.apache.org mailing list asking for a request for comments
on the release.
+ Start a "[DISCUSS]" thread on the dev@couchdb.apache.org 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 =
  

Mime
View raw message