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) - [Installation](#installation)
* [Supported platforms](#supported-platforms) * [Supported platforms](#supported-platforms)
* [Using the `v2` branch](#using-the-v2-branch) * [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) - [Getting Started](#getting-started)
- [Examples](#examples) - [Examples](#examples)
* [Arguments](#arguments) * [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 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 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 $ 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 ## Getting Started
One of the philosophies behind cli is that an API should be playful and full of One of the philosophies behind cli is that an API should be playful and full of