Document what the values of GIMME_GO_VERSION can be

[ryho]

It doesn't need to be too extensive, just a quick addition to the read me and to gimme help
I've seen people use tip, master, stable, etc. What are the possible values and what do they do? I noticed someone using tip in their travis.yml and that test always takes way longer, might be good to mention which ones will take longer.
If I provide 1.8 do I get 1.8.X where X is the latest or 1.8.0?

[ryho]

I think that 1.7 is providing 1.7.0 rather than 1.7.X. Is there a way to request "the latest stable update to the previous version" (something like "stable-legacy") or to get "the always latest version of 1.7" (something like "1.7.X")?

[dmitshur]

1.7 will get you 1.7.0, but 1.7.x will get you the latest 1.7.4 or whatever.

1.x will get you latest stable version.

This is documented at https://docs.travis-ci.com/user/languages/go/#Specifying-a-Go-version-to-use. Agreed it could be documented here too.

[philpennock]

No, because the .x handling is done by Travis, replacing the value it supplies to gimme, not by gimme itself.

gimme has mostly avoided embedding knowledge of specific versions for more than testdata.

[klauspost]

Hmmm. Using 1.9.x gives me:

16.03s$ GIMME_OUTPUT=$(gimme 1.9.x | tee -a $HOME/.bashrc) && eval "$GIMME_OUTPUT"
I don't have any idea what to do with '1.9.x'.
  (using type 'auto')

Am I doing something wrong, or will it only work after Go 1.9.1 is released?

[philpennock]

@klauspost The gimme command does not handle .x; in #110 (moved from #107) I'm asking folks what we should be doing.

Currently it's Travis CI which handles .x, by keeping lists of current versions and deciding how to map supplied versions to real versions. Gimme itself doesn't have that, but does have testdata which might drive things.

People are expecting gimme to handle this, which seems fair. Thus #110.