x/urfave-cli
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update wording around gopkg.in pinning to be more accurate

Browse Source 
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
This commit is contained in:
Jesse Szwedko 2016-09-03 13:18:48 -07:00
parent df95e0708f
commit 4b62cb6b33
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@ -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