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

[Apache Wiki <wi...@apache.org>]

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=81&rev2=82

Comment:
just getting started

  ## page was copied from Release_procedure
  <<Include(EditTheWiki)>>
  
- == Making a Source Release ==
+ = NOTES =
  
- Any Apache CouchDB committer is free to make a source release, but they are usually made by the release team.
+  * 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
+  * 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 
-  * Update the `README` file with important information.
-  * Update the `NEWS` and `CHANGES` files with important information.
-  * Add note about breaking changes to the `NEWS` file if necessary.
-  * Remove "version has not been released" warnings from `NEWS` and `CHANGES` if present.
-  * If working on a branch, make sure `NEWS` and `CHANGES` are synced with trunk.
-  * Update the `acinclude.m4.in` file with version information.
-    * LOCAL_VERSION_MAJOR should be the X in X.Y.Y
-    * LOCAL_VERSION_MINOR should be the X in Y.X.Y
-    * LOCAL_VERSION_REVISION should be the X in Y.Y.X
-    * LOCAL_VERSION_STAGE must always be empty on a release tag.
-      * 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 ===