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=152&rev2=153 Generate a release proposal: {{{ - ./release/generate_proposal.sh CACHE_DIR BRANCH VERSION + ./email/discuss_release.sh CACHE_DIR BRANCH VERSION }}} Replace `CACHE_DIR` with the temporary directory name from the `check_docs.sh` script. @@ -167, +167 @@ So, in this instance, you might run: {{{ - ./release/generate_proposal.sh /tmp/check_docs.sh.9oNHt9 1.3.x 1.3.0 + ./email/discuss_release.sh /tmp/check_docs.sh.9oNHt9 1.3.x 1.3.0 }}} - This command will output some text that you should email to the `d...@couchdb.apache.org` mailing list. + This will output something like: + + {{{ + Email text written to: /tmp/discuss_release.sh.FNISJ9/email.txt + Send the email to: d...@couchdb.apache.org + Files in: /tmp/discuss_release.sh.FNISJ9 + }}} + + Copy the text from that file and send an email to the `d...@couchdb.apache.org` mailing list. = Preparing the Candidate = @@ -198, +206 @@ {{{ Check complete... - Files in: /tmp/build_candidate_remote.sh.DOtlGR + Files in: /tmp/build_candidate.sh.DOtlGR }}} The release candidate and the corresponding `ish` file can be found in this directory. @@ -278, +286 @@ Replace `CANDIDATE_NUMBER` with the candidate number. + So, in this instance, you might run: + + {{{ + ./release/publish_candidate.sh /tmp/build_candidate.sh.DOtlGR 1.3.0 1 + }}} + The candidate number should start at 1 and increase with each successive vote. - ``@@ UNFINISHED`` + If the vote fails, and you're doing a second, you might run: - Update the [[Test_procedure|test procedure]] to use the correct values so that copying and pasting the commands will work. + {{{ + ./release/publish_candidate.sh /tmp/build_candidate.sh.DOtlGR 1.3.0 2 + }}} - If they pass your own tests: + If you attempt to publish a duplicate candidate number, you will get a cryptic Subversion error. + Certificate prompts and password prompts are, however, expected behaviour. - * [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201202.mbox/%3CCA%2BY%2B444JKqhZvfZduqMmqaR1nCZU9Uvts_W9QCjxSfsnFdwmfA%40mail.gmail.com%3E|Call a vote]] on the d...@couchdb.apache.org mailing list. - * Make sure to link to the [[Test_procedure|test procedure]] page. - * When the vote passes, send a [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3c20090722214200.ga11...@tumbolia.org%3E|summary of the vote]] to the d...@couchdb.apache.org mailing list. - The vote email must include the full tree-ish used to prepare the release. + The script is managing a Subversion directory for you, and expects your authorisation for every action taken. - The release manager has the power to abort a vote at any point and for any reason. + When the script has finished, it will output something like: - Please try to make it a good one though! + {{{ + Email text written to: /tmp/publish_candidate.sh.KzG6bd/email.txt + Send the email to: d...@couchdb.apache.org + Files in: /tmp/publish_candidate.sh.KzG6bd + }}} - 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. + Copy the text from that file and send an email to the `d...@couchdb.apache.org` mailing list. + + (You should replace values, or remove sections, as necessary.) + + The vote is now underway. = Preparing the Binary packages = @@ -305, +327 @@ * Dave Cottlehuber <d...@apache.org> (Windows) * Hans J Schroeder <h...@cloudno.de> (Mac OS X) - Ideally, both people would have been involved in the vote thread. + Ideally, both people are going to be involved in the vote thread. Either way, ask them both to prepare binary packages for the release artefacts. @@ -313, +335 @@ = Preparing the Release Notes = + ''Please note that this section of the release procedure is going to be replaced soon.'' + + Create a temporary directory: + + {{{ + mkdir -p /tmp/couchdb + }}} + + Check out the development release notes directory: + + {{{ + svn co https://dist.apache.org/repos/dist/dev/couchdb/notes /tmp/couchdb/notes + }}} + + Create a new directory: + + {{{ + mkdir /tmp/couchdb/notes/Y.Y.Y + }}} + + Replace `Y.Y.Y` with the version you are releasing. + + Change into this directory: + + {{{ + cd /tmp/couchdb/notes/Y.Y.Y + }}} + + Create a new file: + + {{{ + apache-couchdb-Y.Y.Y.html + }}} + + Copy the format of previous release notes. + + A brief description of what CouchDB is, for the announcement emails. + 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. - ''@@ Add step that adds brief description of what CouchDB is, for the announcement emails.'' - Then generate a text only version by running: {{{ @@ -335, +387 @@ 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`. + Add these files, and commit them back to Subversion. - Make sure that these files are owned by the `couchdb` group and are group writable. + = Wrapping Up the Vote = + + You need to wait a minimum of 72 hours. + + A successful vote needs a majority approval and at least three +1 binding votes. + + A binding vote is a vote cast by a member of the PMC. + + Release may not be vetoed, but any -1 votes should be taken seriously. + + The release manager has the power to abort a vote at any point and for any reason. + + Please try to make it a good one though! + + When the vote passes, open this file: + + {{{ + email/result_release.txt + }}} + + Copy the text from that file and send an email to the `d...@couchdb.apache.org` mailing list. + + (You should replace values as necessary.) = Making the Release = - Create a signed tag: + Change in to the admin resources directory: {{{ - git tag -u DEADBEAF Y.Y.Y <tree-ish> + cd couchdb-admin }}} - Use a tag message like this: + Tag the candidate: {{{ + ./release/tag_candidate.sh VERSION CANDIDATE GPG_KEY - CouchDB Y.Y.Y - - Vote results: <URL> }}} - Use the Apache URL shortener to produce the URL: + Replace `VERSION` with the version you are releasing. - https://s.apache.org/ + Replace `CANDIDATE` with the candidate number that passed the vote. - The URL should point to the vote results email you previously sent. + Replace `GPG_KEY` with your GPG key. - Now, push the tag: + The script will do some basic checks to make sure the values look sane. + When the script has finished, it will output something like: + {{{ - git push origin Y.Y.Y + Release dist directory: https://svn.apache.org/repos/asf/couchdb/site/test/release/source/1.3.0 + Files in: /tmp/tag_candidate.sh.bbLyFI }}} Now, follow these steps: - * Copy the release directory to `/www/www.apache.org/dist/couchdb/releases` 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. * Send a pre-announcement email to d...@couchdb.apache.org mailing list, so that downstream distributors can prepare their own announcements. * Wait for all changes to be synced to public mirrors. * Update http://couchdb.apache.org/ to point to the new files.
