readme: add section on versioning

[willnorris]

This does not yet address some of the additional workflows and policies we'll need to adopt as a result. For example, when do we cut new releases, do we attempt to maintain a formal changelog, or at least release notes when we cut a new release, etc. This also requires that we update go docs to call out which methods are exposing preview functionality from the GitHub API.

Fixes #376

[gmlewis]

This sounds good to me.

One thing I'm left wondering is... what does libraryVersion now become?
Do we want to add a section in CONTRIBUTING.md that describes how contributors are expected to bump the libraryVersion on each PR? Or do we only use GitHub tagged releases for this new versioning? (Or both? ...probably not.)

This may all fall under "additional workflows and policies" that you called out in the description above, so maybe it can all be addressed later.

[dmitshur]

Nit: The rest of README.md, and Go style at large uses 1 space between sentences, not two.

Everything I read sounds reasonable and SGTM, up until this part:

We do our best to call out which portions of a method's behavior and/or data are part of a GitHub Preview in the appropriate Go doc.

I don't think we should do that, we should have people look that information up in GitHub documentation. I think it would cause too much churn to deal with in our Go package, and it'd end up being too inaccurate and out of date more often than not. It'd cause merge conflicts, delays in PRs being merged, etc. In the end, I see not nearly enough benefit, but huge downsides.

Also, as Glenn mention, we need to figure out how libraryVersion would intersect with this. Would we change libraryVersion to be semver? Get rid of it completely? Something else?

[gmlewis]

LGTM. Thank you, @willnorris!

[dmitshur]

s/http/https/

[willnorris]

fixed.

[willnorris]

I've created historical tags for v2.0.0 through v15.0.0, corresponding to each time the libraryVersion was bumped. Going forward, we'll need to decide on a release schedule and tag the release using a version number that reflects whatever changes are included in that release.