doc: update usages for v1.1

[Bobgy]

Fixes #103
Fixes #109

[wlynch]

LGTM! I've been bad about staying on top of this for other PRs, but please squash before submission 🙏

[wlynch]

Actually, I'm not sure if we want to have "v2" docs now that we're tracking in the main branch. 🤔

This refers to a version that doesn't technically exist. Let's aim to keep the main README up to date with the current HEAD? We can always maintain versioned docs through release branches.

[Bobgy]

Actually, I'm not sure if we want to have "v2" docs now that we're tracking in the main branch. 🤔

This refers to a version that doesn't technically exist. Let's aim to keep the main README up to date with the current HEAD? We can always maintain versioned docs through release branches.

I'm not sure we want to keep README up to date with the HEAD, because HEAD remains to be the major user facing entrance for documentation. When people visit github.com/google/go-licenses, they immediately see what's in master branch.

I think we can only update default README after maybe a beta release of v2.

For now, I'm proposing this PR -- add a link to point people to the v2 README if they want to try it early and fully fork v2 README to a different file.

[Bobgy]

LGTM! I've been bad about staying on top of this for other PRs, but please squash before submission 🙏

The convention I used was that PRs can have multiple commits, but when it's merged in github -- the merge button has an option to squash its commits. I think that approach is preferred because keeping multiple commits in the PR makes it easier to review.

[Bobgy]

Hi @wlynch, I updated to target this as README of v1.1 release instead.

[Bobgy]

Note, required features for go install are usable starting from go 1.16, so we can simply tell people to use go install now.

[Bobgy]

The doc addresses a lot of user confusions raised in previous issues. I'll merge and release v1.1