Team, Background: For projects based on Go and Containers we need to ship binaries, for example Kubernetes, etcd both ship binaries and maintain stable branches as well. https://github.com/kubernetes/kubernetes/releases https://github.com/coreos/etcd/releases/ Kubernetes for example ships container images to public registeries as well: https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/hyperkube?pli=1 https://github.com/kubernetes/kubernetes/tree/master/cluster/images/hyperkube So here's a proposal based on the really long thread: http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677 The idea is to augment the existing processes for the new deliverables. * Projects define CI jobs for generating binaries and containers (some already do!) * Release team automation will kick builds off when specific versions are released for the binaries and containers (Since Go based projects can do cross-builds, we won't need to run these jobs on multiple architectures which will keep the release process simple) * Just like we upload stuff to tarballs.openstack.org, we will upload binaries and containers there as well * Just like we upload things to pypi, we will upload containers with specific versions to public repos. * Projects can choose from the existing release models to make this process as frequent as they need. Please note that I am deliberately ruling out the following * Daily/Nightly releases that are accessible to end users, especially from stable branches. * Project teams directly responsible for pushing stuff to end users What do you think? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims