asking for 1.10 selects 1.1

[sbinet]

with this .travis.yml file:

go:
  - 1.10

one gets 1.1:

Updating gimme
$ GIMME_OUTPUT="$(gimme 1.1 | tee -a $HOME/.bashrc)" && eval "$GIMME_OUTPUT"
go version go1.1 linux/amd64

to get 1.10, one has to write it like so:

go:
  - "1.10"

and just putting 1.10.x confuses gimme:

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

could we have gimme understand that x.yy.z means any x.yy even if no patch release for x.yy was made yet ?

[BanzaiMan]

Do understand that YAML says 1.10 is a float equivalent to 1.1. It is distinct from a string "1.10". We bend over backwards in many places to accommodate this surprisingly common misconception, but sometimes we lag behind.

[sbinet]

Yes, I understand that.
It surprised me but (in the sense that it caught me off guard) I understand.

What I am suggesting it is to make sure that '1.42.x' always works to pick up '1.42' even if '1.42.1' isn't even out :)

[jmank88]

I don't think gimme understands x at all. IIRC that conversion is done before gimme is called. My memory if foggy, but we went through this last cycle: golang/dep#714 (comment)

[jmank88]

Also, getting a green build that reads 1.10.x but that actually ran 1.9.1 is a very poor user experience. IMHO gimme should reject instead of choosing seeming randomly (we got different fallbacks for linux vs. osx).

[sbinet]

If 1.10 is out and I write 1.10.x I'd expect to get 1.10.
If 1.10.2 is out and I write 1.10.x I'd expect to get 1.10.2.
And if I were to write 1.11.x now, I'd expect to get an error.

Right now, if I write 1.10.x, I get 1.7.4 on Linux. (That's probably something to report in another issue, though...)

[jmank88]

Right now, if I write '1.10.x', I get 1.7.4 on Linux. (That's probably something to report in another issue, though...)

And 1.9.1 on OSX ;)

[krasi-georgiev]

+1 prometheus is using gimme and so far always using the 1.10.x format to avoid updating travis on every go minor change.

[philpennock]

At present, the .x is handled (only) by travis-ci. PR #130 adds .x directly to gimme and I can confirm that 1.10.x maps to 1.10 in that PR.

[philpennock]

The gimme feature to handle 1.10.x is in the master branch, I've no idea when the folks over at Travis will cut a new release and push it to their boxes. nudge nudge :)

[BanzaiMan]

gimme 1.10 should now install Go 1.10.

That go: 1.10 maps to Go 1.1 is a separate issue. See travis-ci/travis-ci#9247

[philpennock]

(For clarification: gimme 1.10 has never installed Go 1.1, AFAIK. It has always done the right thing. The problems have been entirely with how one product parses config files before things reach gimme. I've fixed a bunch of gimme bugs exposed around 1.10 but they're not anything which would have caused the wrong version to be installed.)