Update wording around gopkg.in pinning to be more accurate

Since we have `v1.X` tags, gopkg.in/urfave/cli.v1 will pull the latest
tagged release rather than the `v1` branch. Since there are no tagged
`v2` releases, `gopkg.in` will pull the latest commit of that branch.

Fixes #513

README.md

@@ -23,7 +23,7 @@ applications in an expressive way.
 - [Installation](#installation)
   * [Supported platforms](#supported-platforms)
   * [Using the `v2` branch](#using-the-v2-branch)
-  * [Pinning to the `v1` branch](#pinning-to-the-v1-branch)
+  * [Pinning to the `v1` releases](#pinning-to-the-v1-releases)
 - [Getting Started](#getting-started)
 - [Examples](#examples)
   * [Arguments](#arguments)
@@ -104,11 +104,11 @@ import (
 ...
 ```
 
-### Pinning to the `v1` branch
+### Pinning to the `v1` releases
 
 Similarly to the section above describing use of the `v2` branch, if one wants
 to avoid any unexpected compatibility pains once `v2` becomes `master`, then
-pinning to the `v1` branch is an acceptable option, e.g.:
+pinning to `v1` is an acceptable option, e.g.:
 
 ```
 $ go get gopkg.in/urfave/cli.v1
@@ -122,6 +122,8 @@ import (
 ...
 ```
 
+This will pull the latest tagged `v1` release (e.g. `v1.18.1` at the time of writing).
+
 ## Getting Started
 
 One of the philosophies behind cli is that an API should be playful and full of