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=107&rev2=108 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. + = Preparing the Release Notes = + + Go through the `NEWS` file and expand each bullet point as appropriate. + + Format this document as HTML, and call it something like: + + {{{ + apache-couchdb-Y.Y.Y.html + }}} + + Check that this HTML looks good when used for a draft blog post. + + Then generate a text only version by running: + + {{{ + elinks -dump -no-numbering -no-references apache-couchdb-Y.Y.Y.html > apache-couchdb-Y.Y.Y.txt + }}} + + Check the text only version to make sure that any important links are not lost. + + For example, a JIRA ticket that is not referenced by number. + + Upload these files to `/www/www.apache.org/dist/couchdb/notes/Y.Y.Y` on `people.apache.org`. + = Making the Release = Create a signed tag: @@ -242, +266 @@ * Copy the release directory to `/www/www.apache.org/dist/couchdb` on `people.apache.org`. * Make sure that the release directory and all the files within it are owned by the `couchdb` group and are group writable. * Wait for all changes to be synced to public mirrors. - * Update http://couchdb.apache.org/downloads.html + * Update http://couchdb.apache.org/ to point to the new files. * Send a pre-announcement email to [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list, so that downstream distributors can prepare their own announcements. * Wait for all changes to be synced to the public site. + * Publish a blog post using the HTML version of the release notes. - * Make a [[http://mail-archives.apache.org/mod_mbox/www-announce/201007.mbox/%[email protected]%3E|release announcement]] to the [[http://mail-archives.apache.org/mod_mbox/www-announce/|announce]], [[http://mail-archives.apache.org/mod_mbox/couchdb-user/|couchdb-user]], and [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing lists. + * Send the [[http://mail-archives.apache.org/mod_mbox/www-announce/201007.mbox/%[email protected]%3E|release notes]] to the [[http://mail-archives.apache.org/mod_mbox/www-announce/|announce]], [[http://mail-archives.apache.org/mod_mbox/couchdb-user/|couchdb-user]], and [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing lists. 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.
