Discuss the versioning strategy of builder images

When we started versioning these images, we just started from 0.0.1 and bumped the patch component. We didn't had any SemVer compliance in mind. We should have a strategy in place. For starting the discussion, here is one

1. Use X.Y.Z
2. Bump Z component when we need to update older tags of builder images, to satisfy backport releases of GitLab. For example, if we are currently on builder image 1.2.0, but there is a security backport for a GitLab release that was originally on builder image 1.0.0 which needs an update to the builder image - then we branch off tag 1.0.0, make the changes and tag 1.0.1.
3. Bump Y component when we update component versions or add new OSs. This is our usual scenario.
4. Bump X component when we refactor the base images, build process or structure significantly, like we are doing in !159 (merged).

This means, once !159 (merged) is merged, we cut 1.0.0.

@gitlab-org/distribution WDYT?