And also very important to watch for changes of your dependencies, as they can be quite dynamic. A single review too early or too late in the development process may have misleading results. Watching for commit changes is too time consuming, so watching for releases is a bit easier, especially if you use something like https://newreleases.io or other similar sites.
This will be very neat just as GitHub user experience is so far. Centralization is a questionable, but it looks like that the community values much more the convenience than decentralization and privacy. In any case, it is excellent to have multiple choices beside other registries. I hope that other services like https://newreleases.io will catch up and support this registry as well. But, maybe this would even make them obsolete and everything a bit more centralized.
Thank you very much for Bleve! It was useful for me on a few projects. And, do not be afraid to break things in the future major version, modules are handling that nicely.
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.
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.
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 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.
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.
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.
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.
