Hacker News Reader

Comment by bithavoc | Hacker News Reader

This is so great, although I tried to update my docker container and the official docker container is still in rc.

The Go team doesn't own the official Docker containers and we don't notify the maintainers when we do a release. We probably should.

Maybe they can use https://NewReleases.io to track Go releases.

Golang has an announcements mail list. I'm sure than projects that depend on the language already subscribe to it. Surely.

But sometimes golang docker images are late for a few days which is very annoying if your ci build pipeline depend on them. It would be great if Go team would be able to update docker images as well. And I am sure that this automation would not be so hard to do.

What requirement do you have to update Go's version on the very day it is released?

If you rely on such docker image then upgrade only after it is released.

> What requirement do you have to update Go's version on the very day it is released?

The ability to test / CI that your library works properly?

No, that does not require upgrading to the latest version on the day it is released.

Yeah it does. You'll have downstream users on it as soon as it gets released.

If it’s a critical part of your infra, building your own container images isn’t a huge ask. Use gimme[0] to install your preferred version of Go into the container.

[0]: https://github.com/travis-ci/gimme

That’s what Go’s bets and rc builds are specifically for - to test your code against a new version before it’s available. The only changes to Go during an rc are ceirical bug fixes.

For some organizations unpredictable docker image releases are considered unreliable to use at all. Sometimes the image is updated the same day, sometimes after a few days, earlier even after more than a week.

The gap between developer tools and infrastructure support for them should be as small as possible this days. It's 2019.

My question is: Why do you need to upgrade your developer tools immediately?

I think that the question is, why wouldn't you? There are already a lot of work and testing done on projects that depend on 1.12 features, but using beta and rc releases. Final 1.12 version would just confirm that everything works, but without docker image, testing on staging infrastructure is delayed even the final version is out.

This is why I have https://NewReleases.io configured to track both Go GitHub releases as well as golang image tags on Docker Hub.

> I think that the question is, why wouldn't you?

We already have a reply to that in your case with the availability of the docker image.

In general, people do not rush into upgrading to a new release of any software because it's risky.

> There are already a lot of work and testing done on projects that depend on 1.12 features

The only reason I can think of is that you have a requirement to support TLS 1.3.

And there is no 'delay', as, surely, you plan based on the availability of everything you need (or build your own container image).

So you do not need it as you do not want to use it too soon. That is cool. Others may need docker image release aligned with regular release, and I think that there is nothing wrong with that. Especially for the people that are trying to contribute to Go by testing beta and rc releases.

You can always make your own base image with go installed that you update the instant you need to, if you really can't wait for the team responsible for the accepted docker image to do it...

I had to check what the Go docker image does.... It does NOTHING, it just builds and installs Go, why would you even need a container for this?

Either as a base for a development environment, or a disposable container to compile your go programs.

For example, compiling your program with a different version of Go can be done just by changing the tag on your compile command, and doesn't require that you have any development tools or compilers installed on your machine (except docker).

It's super useful to be able to build go binaries in a CI system. It provides the Go toolchain in a container so that you can just use it as a mini-executor. For instance, in Jenkins you can hook up the Jenkins master to a Kubernetes cluster and run your CI in a docker container. The Go docker container is great for this. I can run `go test ...` etc.

Also, when building a container with a Go binary, it's a great base to build from. You can use Docker Multistage Builds[1] to build your binary in the Go container, then copy it out into a minimal container all in the same Dockerfile.

[1]: https://docs.docker.com/develop/develop-images/multistage-bu...

Reply on news.ycombinator.com