Switch `latest` container image tag to be the last stable version

[vincepri]

To avoid confusion, I'd like to propose we switch builds on master to build master and use the latest tag to target instead the latest stable release.

/priority important-soon
/kind feature

[detiber]

The latest tag should be for development purposes only, so I think having it track master makes sense... latest stable release is an artifact in the prod bucket, not the staging bucket.

[ncdc]

I consider latest to not be git master, but instead the most recent stable release. However, latest is not particularly informative, and it can be dangerous when it transitions from one major release to the next (in CAPI terms, that would be moving from v0.2.4 to v0.3.0). Given that the Kubernetes image pull policy defaults to always when the tag is latest, I'm not sure that having latest mean "latest stable version" is going to yield what we want.

How about we use master for git master, and then create a set of tags for our releases, such as v0.2 (latest in v0.2.x, e.g. v0.2.4) and the more specific v0.2.4. When we come out with v0.2.5, the v0.2 tag shifts to point at the newer patch release. And eventually, if/when we get to 1.x and beyond, we could have v1, v1.0 (latest v1.0.x), v1.1 (latest v1.1.x), and the specific v1.0.1, v1.2.3, etc?

[vincepri]

@ncdc And deprecate latest going forward? If so, that breaking change can make sense for v0.3

[timothysc]

There is a ton of precedent that we should be following:

https://hub.docker.com/_/golang

:latest - latest stable
:v0.2 - latest v0.2
:v0.2.x - specific tag
:master - tip of master, use at your own peril

[detiber]

Really, I don't think anyone or anything outside of CI or release tooling should be consuming the staging images.

[timothysc]

:master is highly useful for consumption by downstream folks who may be doing their own qualification against tip b/c they don't want to wait till a release to find out if something is busted.

This can sometimes include deployment of dev clusters on a nightly basis. Back at RH, we setup the death-star to do exactly this b/c if we waited for release we would always find p0 bugs after the cut which was too late.

That said, the pattern I described above is solid and well established best practices across a number of projects. +1 to move forwards.

[ncdc]

Any other feedback - @akutz @rudoi @CecileRobertMichon @juan-lee @andrewsykim @justaugustus ?

[vincepri]

we setup the death-star to do exactly this b/c if we waited for release we would always find p0 bugs after the cut which was too late

I love this

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[vincepri]

I think this can be closed given that we're not building latest anymore

/close