You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by Apache Wiki <wi...@apache.org> on 2012/02/10 20:39:37 UTC

[Couchdb Wiki] Trivial Update of "Release_procedure" by DaveCottlehuber

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 DaveCottlehuber:
http://wiki.apache.org/couchdb/Release_procedure?action=diff&rev1=90&rev2=91

Comment:
add TOC and move headings to h1

  <<Include(EditTheWiki)>>
  
- == Making a Source Release ==
+ = Making a Source Release =
  
  Any Apache CouchDB committer is free to make a source release, but they are usually made by the release team.
  
  If you'd like to help out with making a release, lets us know on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list.
  
+ <<TableOfContents(2)>>
+ 
- === Checklist ===
+ = Checklist =
  
   * Update the `README` file with important information.
   * Update the `NEWS` and `CHANGES` files with important information.
@@ -23, +25 @@

       * When this is set, it indicates a development version. It is set on branches or on trunk so that the release number includes the source code revision number, which can be useful for development builds.
   * Update the [[Breaking_changes]] document.
  
- === Preparing the Community ===
+ = Preparing the Community =
  
  Call a vote on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list asking for a request 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.
  
- === Preparing the Release ===
+ = Preparing the Release =
  
  Find a list of branches:
  
@@ -62, +64 @@

  cd Y.Y.Y
  }}}
  
- === Release Signing ===
+ = Release Signing =
  
  You will need a GPG key pair to sign the release.
  
@@ -90, +92 @@

  gpg --list-keys
  }}}
  
- === Creating the Release Artefacts ===
+ = Creating the Release Artefacts =
  
  To build the source for distribution you should then run the following command:
  
@@ -105, +107 @@

   * apache-couchdb-Y.Y.Y.tar.gz.md5
   * apache-couchdb-Y.Y.Y.tar.gz.sha
  
- === Checking the Release Contents ===
+ = Checking the Release Contents =
  
  Create a temporary directory:
  
@@ -155, +157 @@

  
  Do not upload the exported tag directory, of course. That was only for testing.
  
- === Calling a Vote ===
+ = Calling a Vote =
  
   * [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3C20090716211304.GA17172@tumbolia.org%3E|Call a vote]] on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list.
   * Make sure to link to the [[Test_procedure|test procedure]] page.
@@ -169, +171 @@

  
  A vote can only pass if there are at least three +1 votes. These votes can come from anyone, including non-committers, and in fact, everyone is encouraged to partake in and vote on each release. However, it is preferable that at least three +1 votes come from the committers, or better yet, the PMC. Once three +1 votes have been counted, the vote can pass. However, if anyone votes -1 or expresses any serious concern, that should be addressed. Usually, this will be cause to abort the vote. A vote can only be closed after three working days. This allows most people a chance to test and vote on the release.
  
- === Making the Release ===
+ = Making the Release =
  
   * Create a signed tag, using the same key as used to signed the release, pointing to the release tree-ish and a link to the [VOTE RESULTS] message on the dev mailing list.
   * Push the signed tag with 'git push origin Y.Y.Y'.
@@ -182, +184 @@

  
  At each stage of the actual release, it is expected that a person can follow the trail of changes back to the source. Because most of these systems are slow, things must be done in the correct order. It would be unfortunate if `downloads.html` listed a release that was not available on a local mirror, or that was missing a corresponding tag in the Git repository. The changes should always propagate from the source, to the `dist` directory, to the mirrors, to `downloads.html`, and finally to the actual release announcement.
  
- === Doing Housekeeping ===
+ = Doing Housekeeping =
  
   * Add a new release section to `NEWS` and `CHANGES` on trunk if not already present.
   * Add a new release section to `NEWS` and `CHANGES` on Y.Y.x the branch if not already present.
@@ -195, +197 @@

   * Call a discussion on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list about archiving old releases.
     * To archive an old release, remove it from `downloads.html` and then delete the corresponding directory from the `dist` directory. Do not worry about the release artefacts no longer being available, they are automatically mirrored to the Apache archive site and will remain there even after they are deleted from the main `dist` directory.
  
- == Useful Resources ==
+ = Useful Resources =
  
   * http://www.apache.org/dev/release.html
   * http://incubator.apache.org/guides/releasemanagement.html#best-practice