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] Trivial Update of "Release_procedure" by DaveCottlehuber
Date Fri, 10 Feb 2012 19:39:37 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 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

Mime
View raw message