Add release summary, some touch-ups

HOW_TO_RELEASE.md

@@ -2,78 +2,90 @@
 
 Time required: about an hour.
 
+These instructions assume that `upstream` refers to the main repository:
+```
+$ git remote -v
+{...}
+upstream        https://github.com/pydata/xarray (fetch)
+upstream        https://github.com/pydata/xarray (push)
+```
+
+ 0. Write a release summary: ~50 words describing the high level features. This
+    will be used in the release emails, tweets, GitHub release notes, etc. 
+    I (@max) find it helpful to use a PR given I'm not always familiar with all the
+    features of the release, and the summary is distributed widely.
+
  1. Ensure your master branch is synced to upstream:
-      ```
-      git pull upstream master
-      ```
+     ```sh
+     git pull upstream master
+     ```
  2. Get a list of contributors with:
-    ```
+    ```sh
     git log "$(git tag --sort="v:refname" | sed -n 'x;$p').." --format=%aN | sort -u | perl -pe 's/\n/$1, /'
     ```
-    or by substituting the _previous_ release in:
-    ```
-    git log v0.X.Y-1.. --format=%aN | sort -u | perl -pe 's/\n/$1, /'
+    or by substituting the _previous_ release in {0.X.Y-1}:
+    ```sh
+    git log v{0.X.Y-1}.. --format=%aN | sort -u | perl -pe 's/\n/$1, /'
     ```
     Add these into `whats-new.rst` somewhere :)
  3. Look over whats-new.rst and the docs. Make sure "What's New" is complete
-    (check the date!) and consider adding a brief summary note describing the
-    release at the top.
+    (check the date!) and add the release summary at the top.
     Things to watch out for:
     - Important new features should be highlighted towards the top.
     - Function/method references should include links to the API docs.
     - Sometimes notes get added in the wrong section of whats-new, typically
       due to a bad merge. Check for these before a release by using git diff,
-      e.g., `git diff v0.X.Y whats-new.rst` where 0.X.Y is the previous
+      e.g., `git diff v{0.X.Y-1} whats-new.rst` where {0.X.Y-1} is the previous
       release.
  4. If you have any doubts, run the full test suite one final time!
-      ```
+      ```sh
       pytest
       ```
  5. Check that the ReadTheDocs build is passing.
  6. On the master branch, commit the release in git:
-      ```
-      git commit -am 'Release v0.X.Y'
+      ```s
+      git commit -am 'Release v{0.X.Y}'
       ```
  7. Tag the release:
+      ```sh
+      git tag -a v{0.X.Y} -m 'v{0.X.Y}'
       ```
-      git tag -a v0.X.Y -m 'v0.X.Y'
-      ```
- 8. Build source and binary wheels for pypi:
-      ```
-      git clean -xdf  # this deletes all uncommited changes!
+ 8. Build source and binary wheels for PyPI:
+      ```sh
+      git clean -xdf  # this deletes all uncommitted changes!
       python setup.py bdist_wheel sdist
       ```
  9. Use twine to check the package build:
+      ```sh
+      twine check dist/xarray-{0.X.Y}*
       ```
-      twine check dist/xarray-0.X.Y*
-      ```
-10. Use twine to register and upload the release on pypi. Be careful, you can't
+10. Use twine to register and upload the release on PyPI. Be careful, you can't
     take this back!
-      ```
-      twine upload dist/xarray-0.X.Y*
+      ```sh
+      twine upload dist/xarray-{0.X.Y}*
       ```
     You will need to be listed as a package owner at
     https://pypi.python.org/pypi/xarray for this to work.
 11. Push your changes to master:
-      ```
+      ```sh
       git push upstream master
       git push upstream --tags
       ```
 12. Update the stable branch (used by ReadTheDocs) and switch back to master:
-     ```
+     ```sh
       git checkout stable
       git rebase master
-      git push upstream stable
+      git push --force upstream stable
       git checkout master
      ```
     It's OK to force push to 'stable' if necessary. (We also update the stable 
-    branch with `git cherrypick` for documentation only fixes that apply the 
+    branch with `git cherry-pick` for documentation only fixes that apply the 
     current released version.)
-13. Add a section for the next release (v.X.Y+1) to doc/whats-new.rst:
+13. Add a section for the next release {0.X.Y+1} to doc/whats-new.rst:
      ```
-     .. _whats-new.0.X.Y+1:
+     .. _whats-new.{0.X.Y+1}:
 
-     v0.X.Y+1 (unreleased)
+     v{0.X.Y+1} (unreleased)
      ---------------------
 
      Breaking changes
@@ -96,19 +108,19 @@ Time required: about an hour.
      ~~~~~~~~~~~~~~~~
      ```
 14. Commit your changes and push to master again:
-      ```
+      ```sh
       git commit -am 'New whatsnew section'
       git push upstream master
       ```
     You're done pushing to master!
 15. Issue the release on GitHub. Click on "Draft a new release" at
-    https://github.com/pydata/xarray/releases. Type in the version number, but
-    don't bother to describe it -- we maintain that on the docs instead.
+    https://github.com/pydata/xarray/releases. Type in the version number
+    and paste the release summary in the notes.
 16. Update the docs. Login to https://readthedocs.org/projects/xray/versions/
     and switch your new release tag (at the bottom) from "Inactive" to "Active".
     It should now build automatically.
-17. Issue the release announcement! For bug fix releases, I usually only email
-    [email protected]. For major/feature releases, I will email a broader
+17. Issue the release announcement to mailing lists & Twitter. For bug fix releases, I 
+    usually only email [email protected]. For major/feature releases, I will email a broader
     list (no more than once every 3-6 months):
       - [email protected]
       - [email protected]