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:49:53 UTC
[Couchdb Wiki] Update of "Binary_Releases" by DaveCottlehuber
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.
The "Binary_Releases" page has been changed by DaveCottlehuber:
http://wiki.apache.org/couchdb/Binary_Releases?action=diff&rev1=82&rev2=83
Comment:
v1 ready for 1.2.0 release
## page was copied from Release_procedure
<<Include(EditTheWiki)>>
+
+ This page details how Windows binaries are validated and voted on. Any Apache CouchDB committer is free to make a binary snapshot or release, but they are usually made by the release team. There is an important distinction between snapshots and releases, namely:
+
+ * Snapshots may be provided at any time, and have no significance or expectations attached to them
+ * Releases must be cut from the same source tag or commit sha used for a preceding Source Release
+
+ This distinction ensures that the user community can rely on the same functionality cross-platform for Releases, and that the developer community is not obligated to maintain or support snapshots.
+
+ <<TableOfContents(2)>>
+
+ = Introduction =
+
+ Following an official source vote, a Windows binary is created. The procedure for this is documented in [[https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=INSTALL.Windows;hb=HEAD|INSTALL.Windows]] and a scripted approach is available in the appropriate branch of [[https://github.com/dch/glazier/|glazier]].
+
+ After the binary is built, it is then [[http://www.apache.org/dev/release-signing.html#sign-release|signed]] and uploaded to the appropriate committer's [[https://people.apache.org/~id|apache site]].
+
+ The release manager will send a notice to the [[mailto:user@couchdb.apache.org|user@ mailing list]], requesting a vote on the new artefact. This follows the general [[Release_procedure|CouchDB release procedure]].
+
+ = Testing =
+
+ Overall we are interested that the binary is malware free, correctly signed, and digests match, and functionality matches that of the original source tarball.
+
+ * [[http://www.apache.org/info/verification.html|Verify]] the GPG [[http://www.apache.org/dev/release-signing.html#verifying-signature|signature]]. Additional tips are available at [[http://gpg4win.de/handbuecher/novices.html|Introduction to GPG for Windows]].
+ * Validate the MD5 and SHA digests using [[http://md5deep.sourceforge.net/| md5 and sha for Windows]] or similar
+ * Unpack the archive either directly or using the [[http://innounp.sourceforge.net/|Inno setup unpacker]]
+ * Confirm using antivirus software there are no viruses or malware present. Microsoft provides the free [[http://windows.microsoft.com/en-GB/windows/products/security-essentials|Security Essentials]].
+ * Double-check `README`, `INSTALL.Windows`, `NEWS`, `LICENSE`, and `CHANGES` files are present in {{{%COUCHDIR%/share/doc/couchdb/}}} and contents is appropriate. At present these are gzipped but this should be fixed, and added as shortcuts.
+ * If required, run the installer into a separate directory and start CouchDB via the provided {{{couchdb.bat}}} script.
+ * Run Firefox >=4, launch Private Browsing mode, and disable caching by setting both {{{browser.cache.disk.enable = false}}} and {{{network.http.use-cache = false}}} temporarily.
+ * Use Futon to run the basic [[http://127.0.0.1:5984/_utils/verify_install.html|user verification]] tests as well as the full [[http://127.0.0.1:5984/_utils/couch_tests.html?script/couch_tests.js|dev test suite]].
+ * Some tests may periodically depending on the speed of your PC and the phases of the moon. It's fine to re-try a few times, or to test over LAN connection rather than localhost.
+
+ = Voting and Voters =
+
+ * [[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.
+ * Ensure you link to the [[Binary_Releases#Testing|test procedure]].
+
+ If you are voting:
+
+ * Reply to the original Binary Release announcement - for example; {{{
+ +1
+ Windows 7 x64
+ Firefox 10.12
+ signature OK
+ md5 & sha OK
+ No malware
+ Futon tests failed
+ [... tedious details ommitted.. ]
+ }}}
+
+ * After 72 hours have elapsed without any -1 votes, and with at least 3 +1 votes, send a confirmation.
+ * If aborted, ensure a summary is sent out with any follow-up actions required, and by whom.
+ * Full details are on the main CouchDB [[Release_procedure|Release procedure]].
+
+ = Release =
+
+ On a successful vote, three things must be updated:
+
+ * Approved binaries with sha/md5/asc keys to be moved into the {{{dist}}} environment
+ * Subsequent update of CouchDB downloads page
+ * Once these are available on mirrors, the confirmation announcement can be sent.
= NOTES =
* currently working with HTTPD team to see if the new fancypants code signing is usable
* will likely roll releases of 1.2.0 in the usual fashion and use pgp keys to validate it
+ * still need way of referencing the detailed build process, and labelling artefacts.
- * check with nslater on best way to handle this; I guess package/vote/upload is simplest
- * also need to sort out where to host the damn thing. infra@ says people.a.o is not good
- for the actual releases; mirrors might be OK for the releases though. Snaps have to go
- somewhere, I am still partial to github simply because it tracks the number of downloads
- when considering retiring them.
- * most important issue ATM is how to reference the build process as I continually fiddle
- with it, and how to name the artefacts consistently.
-
- == Making a Binary Release [DRAFT] ==
-
- Any Apache CouchDB committer is free to make a binary snapshot or release, but they are usually made by the release team. There is an important distinction between snapshots and releases, namely:
-
- * Snapshots may be provided at any time, and have no significance attached to them.
- * Releases must be cut from the same source tags or commit used for a preceding Source Release
-
- This distinction ensures that the user community can rely on the same functionality cross-platform for Releases.
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.
- === Checklist ===
-
- * Check out the source code via git; for releases using the appropriate tag referred to in the Source Release announcement.
- * Double-check `README`, `INSTALL.Windows`, `NEWS`, and `CHANGES` files
- * Download prebuilt Erlang/OTP and CouchDB pre-requisite libraries if required
- * Make the build, including the final installer package
- * On a fresh system, first
-
- === 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 ===
-
- It is generally a good idea to work under a clean temporary directory.
-
- You can then run the following commands:
-
- {{{
- git archive --prefix=Y.Y.Y/ -o Y.Y.Y.tar <tree-ish>
- tar xf Y.Y.Y.tar
- }}}
-
- You must then use the `Y.Y.Y` directory to prepare the release.
-
- === Release Signing ===
-
- You will need a GPG key pair to sign the release.
-
- If you do not have one already, see the Useful Resources section for more help.
-
- It is generally better if your key is also signed by other people.
-
- Your public key must be added to:
-
- * http://www.apache.org/dist/couchdb/KEYS
-
- You should also upload your key to a public key server for good measure.
-
- Edit Makefile.am so that `gpg` uses your key ID.
-
- ''We should probably make this a command line option.''
-
- You can find your key ID by running:
-
- {{{
- gpg --list-keys
- }}}
-
-
- === Creating the Release Artefacts ===
-
- To build the source for distribution you should then run the following command:
-
- {{{
- ./bootstrap && ./configure && make distsign
- }}}
-
- If everything was successful you should see the following files in the working directory ready for distribution:
-
- * apache-couchdb-Y.Y.Y.tar.gz
- * apache-couchdb-Y.Y.Y.tar.gz.asc
- * apache-couchdb-Y.Y.Y.tar.gz.md5
- * apache-couchdb-Y.Y.Y.tar.gz.sha
-
- === Checking the Release Contents ===
-
- Create a temporary directory:
-
- {{{
- mkdir /tmp/couchdb
- }}}
-
- Move the release files to the temporary directory:
-
- {{{
- mv apache-couchdb* /tmp/couchdb
- }}}
-
- Change to the temporary directory:
-
- {{{
- cd /tmp/couchdb
- }}}
-
- Then unpack another copy of the source tarball
-
- {{{
- tar xf Y.Y.Y.tar
- }}}
-
- Then compare the tarball with the exported tag directory:
-
- {{{
- diff -r apache-couchdb-Y.Y.Y Y.Y.Y
- }}}
-
- Use your judgment here to figure out if anything is missing, or has been included by mistake.
-
- Upload the release files to your `public_html` directory on `people.apache.org` and make sure they are world readable.
-
- Do not upload the exported tag directory, of course. That was only for testing.
-
- === 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.
- * When the vote passes, send a [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3C20090722214200.GA11737@tumbolia.org%3E|summary of the vote]] to the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list.
-
- The vote email must include the full tree-ish used to prepare the release.
-
- 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!
-
- 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 ===
-
- * 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'.
- * 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
- * Wait for all changes to be synced to the public site.
- * Make a [[http://mail-archives.apache.org/mod_mbox/www-announce/201007.mbox/%3C029B8F80-6C99-41C0-B47C-A334667E25BA@apache.org%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.
-
- 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 ===
-
- * 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.
- * Add "version has not been released" warnings to these release sections if not already present.
- * [[https://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310780|Update versions]] in JIRA.
- * If the currently released version is 0.1.0, JIRA should have options for 0.1.1, 0.2.0, and 0.3.0.
- * The released version should be marked as released in JIRA.
- * Update the links on this page to most recent email archives.
- * Update branches, trunk, and site with security changes not documented in the released.
- * 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 ==
-
- * http://www.apache.org/dev/release.html
- * http://incubator.apache.org/guides/releasemanagement.html#best-practice
- * http://www.apache.org/foundation/voting.html
- * http://www.apache.org/dev/openpgp.html
- * http://www.apache.org/dev/release-signing.html
- * http://www.apache.org/info/verification.html
-