On Wed, Oct 5, 2016 at 9:06 AM, Mohammed Ahmed <moahmed at redhat.com> wrote: > > > On Mon, Oct 3, 2016 at 8:42 PM, Troy Dawson <tdawson at redhat.com> wrote: >> >> On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh <mail-lists at karan.org> >> wrote: >> > On 30/09/16 12:22, Mohammed Ahmed wrote: >> >> Even if there aren't any updates to 1.2 containers on toe repos, its >> >> still possible the containers might get rebuilt from other triggers, >> >> such as base image rebuilds and so on. >> >> >> > >> > is there a precidence here ? have there been updates to a prev release ? >> > I guess the way the Dockerfile.CentOS went into 1.2 would potentially >> > constitute a change in pre-code, since Master/ at the time was already >> > 1.3Alpha, but is there another example for say a bugfix or a security >> > update ? >> > >> > Another way to look at this might be - is there a LTS like model in >> > openshift origin ? >> > >> >> Nope >> >> This brings up a very good point I hadn't even thought about. >> We're trying to treat a rotating product (designed to only use the >> latest version) in an enterprise / LTS way. >> >> At the moment, I don't have anything else to say, as I said, I hadn't >> even thought about it until now. >> >> Troy > > So how do we want to proceed with this. Build only the latest containers by > updating branch in container-index every time there is a release, or > do we want to update the dockerfiles to use more specific rpms by version > (will require maintenance of the rpms). In the case of latter we might > need LTS. > We talked about this during our Paas SIG meeting. We have decided to follow the upstream support model, which is to only support the latest release. So we will only build 1.3 images and not worry about the 1.2 images. I have created a support page for OpenShift Origin on CentOS. https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Origin-Support On a related subject, once we get the rpm build automation in place (both in upstream origin spec/tito code, as well as the CentOS testing/build infrastructure) we do have an paas7-openshift-future tag that we can use to build and push beta's and release candidates. So, while we won't be supporting older releases, we can hopefully become a place that people can test/use the latest and greatest. (even if it's not stable) Troy