Docs: Add a few missing steps to release docs

* The step about the changelog did not mention that the default
  behaviour based on the last tag found in master history does not
  work. It ends up summarising several years of history since
  v1.12.0, which was a master commit. I assume one is meant to
  find a commit in master right before the release (e.g. the
  preparation commit), and use its SHA1 hash for the
  `-s` (start) option.

* Document some of the things typically done in the changelog.

* Mention `mailmap` as the way to avoid duplicate entries.
  It seems duplicate entries were sometimes manually omitted,
  which suggests some releasers knew and some not.

* Resolve the git-extras url (redirect).

* Remove the `npm install` step after cloning jquery-release.
  This is a potential security hazard (!), and generally not needed
  given we already commit the needed deps to jquery-release.git.

* Add `npm install -g grunt-cli` as a needed step because
  jquery-release fails otherwise. We may want to improve that at
  some point, but document it for now.

* Document roughly what the jquery-release script does.

* Convert prose about `qunit-git.js` into a bullet point.
  I only noticed this additional prose when writing this commit.
  I'm hoping this a bullet point makes it harder to miss.

* Link the text about the qunit-git "build" to the url of the
  Jenkins job that does this.

* Mention the current website repo.

* Change `git push --tags` to `git push --follow-tags` so that
  it does both the neccecary bit (push the tags), as well as the
  expected bit (update master). The latter was missing/implied.

Author: Krinkle

RELEASE.md

@@ -2,14 +2,20 @@
 
 The following guide walks you through releasing a new version of QUnit. If anything in the following process is found to be inaccurate or unclear, please update this document after you finish the release process so that future releases are easier.
 
-## Preparing the Release
+## Preparing the release
 
 Ensure that all requested changes have made it into the `master` branch of the repo for the pending release. For patch releases, ensure all bug fixes have landed; for minor releases, ensure all features have been included. Major releases will likely have their own special checklist.
 
 Next, checkout the current `master` version of the repo and do the following:
 
-* Install [git-extras](https://github.com/visionmedia/git-extras) and run `git changelog` to update `History.md`. Clean up the changelog, removing merge commits, whitespace cleanups or other irrelevant commits. Refer to the formatting of previous entries when in doubt.
-* Run `grunt authors` and manually add any new authors to `AUTHORS.txt`. The order of this list doesn't change, so you should compare starting at the end.
+* Install [git-extras](https://github.com/tj/git-extras) and run `git changelog -s <SHA1 of last preparation commit>` to update `History.md`. Clean up:
+  * Replace `n.n.n` in the top section with the next release,
+  * Ensure the previous release notes are still there,
+  * Ensure there is no leading or trailing whitespace on the new lines,
+  * Remove any Build or Tests commits that are irrelevant for users,
+  * Refer to the formatting of previous entries when in doubt.
+* Install `grunt-cli` globally (`npm install -g grunt-cli`).
+* Run `grunt authors` and manually add any new authors to `AUTHORS.txt`. The order of this list doesn't change, so you should compare starting at the end. If you see duplicate entries proposed by the output of `grunt authors`, use the `mailmap` file to add entries for the canonical name and/or e-mail address, then run the grunt command again.
 * Update the version property in `package.json` to have the right `-pre` version (e.g., if releasing version `2.3.0`, the version should be `2.3.0-pre`). This is not necessary for patch releases.
 
 Commit all of the above with the following message:
@@ -18,11 +24,11 @@ Commit all of the above with the following message:
 
 Replace `@VERSION` with the version number you are releasing.
 
-For the final preparatory step, push your new commit to `master` on GitHub. In order to do this, you'll need to disable branch protections for administrators. This can be done [here](https://github.com/qunitjs/qunit/settings/branch_protection_rules/511767). Once you're done with the release process, be sure to reenable any protections you disabled.
+For the final preparatory step, push your new commit to `master` on GitHub. In order to do this, you'll need to disable branch protections for administrators. This can be done [here](https://github.com/qunitjs/qunit/settings/branch_protection_rules/511767). Once you're done with the release process, be sure to re-enable any protections you disabled.
 
-## Performing the Release
+## Performing the release
 
-For the actual release, we will use [QUnit's fork of jquery-release](https://github.com/qunitjs/jquery-release).
+For the actual release, we will use [QUnit's fork of jquery-release](https://github.com/qunitjs/qunit-release).
 
 :warning: **WARNING** :warning:
 > Before attempting the process below, make sure you have the proper permissions to publish to the jQuery CDN or else you will run into issues. If you have any doubts, ask someone who has done a release before to verify for you.
@@ -31,53 +37,63 @@ For the actual release, we will use [QUnit's fork of jquery-release](https://git
 
 Always start this process from a fresh clone of the release repo:
 
-	git clone https://github.com/qunitjs/jquery-release.git
-	cd jquery-release
-	npm install
+	git clone https://github.com/qunitjs/qunit-release.git
+	cd qunit-release
 
-Then simply run the script:
+Then, simply run the script (requires `grunt-cli` to be installed globally):
 
 	node release.js --remote=qunitjs/qunit
 
-Follow the prompts along the way and you should be all good. This process will create a new release and tag, push it to GitHub, and publish it to NPM, Bower, and the jQuery CDN.
+Follow the prompts along the way and you should be all good. This process:
+* Creates a new clone of <https://github.com/qunitjs/qunit> under `__release` in the current directory (that's where you can check files during various steps).
+* Creates a new release commit, tags it, and pushes it to GitHub.
+* Creates a commit that bumps master to the next `pre` version, and pushes it to GitHub.
+* Publishes the release to bower.
+* Publishes the release to npm.
+* Publishes the release to the jQuery CDN.
 
 You can verify all of the above were correctly published by using the following:
 
-- Bower: `bower info qunit`
-- NPM: `npm view qunit`
-- CDN: visit `https://code.jquery.com/qunit/qunit-x.x.x.js`
+* Bower: Run `bower info qunit` and verify the latest version number
+* NPM: Visit <https://www.npmjs.com/package/qunit>
+* CDN (release): Visit <https://code.jquery.com/qunit/qunit-x.x.x.js> (replacing `x.x.x` with the release number)
+* CDN (pre-release): Visit <https://code.jquery.com/qunit/qunit-git.js> and ensure that
+  the next `pre` version was built and published. Note that it may take a couple minutes for this version to update while [the build](http://jenkins.jquery.com/job/QUnit/) happens.
 
-Additionally, we publish a new `git` version of QUnit after every change, so we should verify that is still working. You can do so by visiting `https://code.jquery.com/qunit/qunit-git.js` and ensuring the version number matches the latest `-pre` version. Note that it may take a couple minutes for this version to update as the build happens.
-
-## Updating the Website
+## Updating the website
 
 Once you have successfully published the new release, we need to update the website.
 
-As with QUnit itself, checkout the current `master` version of the website repo, ensuring that any necessary updates for this release have made it into the code.
+    git clone [email protected]:qunitjs/qunitjs.com.git
+    cd qunitjs.com
+
+Checkout the latest `master` branch of the website repo.
+
+If this release made any deprecating or breaking changes, check the examples and cookbooks and update them if they don't yet reflect the current best practices.
 
-Next, do a find and replace of the previous version number and insert the new version number (excluding `package.json`, it will be updated separately). Commit those changes with the following message:
+Next, do a find and replace of the previous version number and insert the new version number (**do not** update `package.json`, that will be done separately). Commit these changes with the following message:
 
 	All: Update url and version to @VERSION
 
-Next, update the website version to the next logical number. Usually, this will be the same as `@VERSION`, but occassionally the website will be a patch version ahead if a bug occurred in the website itself:
+Next, use the `npm` command to tag the next website release. Usually, this will be the same as `@VERSION`, but the website will occasionally be a patch version ahead if a bug occurred in the website itself:
 
 	npm version @WEBSITE_VERSION
 
 The above command will change the version in `package.json`, commit it, and tag it. Next, just push the new version to `master`:
 
-	git push --tags
+	git push --follow-tags
 
 It is _important_ that you push the tag as that is what triggers a new website build and deployment.
 
 Check the website in a few minutes after a build completes to verify it is updated.
 
 If the website does not appear to be updating, you should check the Webhook to ensure a build was properly triggered. This can be done by going to the [Webhook Settings](https://github.com/qunitjs/qunitjs.com/settings/hooks) and ensuring the two "builder" hooks are "green".
 
-## Updating the API Documentation
+## Updating the API documentation
 
 The QUnit API documentation is published automatically via [GitHub Pages](https://pages.github.com/) in the `docs` directory of the main repository. Since it is published automatically after every change you do not need to do anything special during a release.
 
-## Final Steps
+## Final steps
 
 You're almost there! Make sure you update [GitHub releases](https://github.com/qunitjs/qunit/releases) using the changelog from `History.md`.