You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Golang uses $major.$minor version names for patch version 0. Golang builder uses the same naming scheme for the "latest patch version" image. Given an image name golang-1.6 it's not clear to a go developer whether that means 1.6.3 or 1.6.0.
What do you think about using 1.6.x as image name for "the latest patch version"?
The text was updated successfully, but these errors were encountered:
Actually, for me (and probably for others like @fabxc), I think it is less-confusing to have 1.6 as a shortcut for the latest 1.6.x version. Lately, we got confused because Travis (with gimme), doesn't do that.
The logic of "1.6", which means the latest "1.6.x", also apply to a lot of official and non-official docker images. It simplify a lot of config updates.
I'm not in favor of changing that, even if Golang use 1.6 as 1.6.0.
Actually, for me (and probably for others like @fabxc), I think it is less-confusing to have 1.6 as a shortcut for the latest 1.6.x version. Lately, we got confused because Travis (with gimme), doesn't do that.
I think that's exactly @grobie 's point: By mixing both ways, we get confused. Since we won't be able to change Go's way, we can avoid the mix-up by using the unambiguous 1.6.x scheme.
In any case, shame on Go for making up their own versioning scheme. (It already confused my with their rc naming.)
Golang uses
$major.$minor
version names for patch version0
. Golang builder uses the same naming scheme for the "latest patch version" image. Given an image namegolang-1.6
it's not clear to a go developer whether that means1.6.3
or1.6.0
.What do you think about using
1.6.x
as image name for "the latest patch version"?The text was updated successfully, but these errors were encountered: