On Thu, Oct 6, 2016 at 10:07 PM, Troy Dawson <tdawson@redhat.com> wrote:
On Wed, Oct 5, 2016 at 9:06 AM, Mohammed Ahmed <moahmed@redhat.com> wrote:
>
>
> On Mon, Oct 3, 2016 at 8:42 PM, Troy Dawson <tdawson@redhat.com> wrote:
>>
>> On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh <mail-lists@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. 

Sounds good.  

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)

So this should leave one last doubt. Do we tag the containers coming from the origin repo, with only the version tag as
we currently are or tag them as latest or both (version tag and latest tag).

Once the infra is in place, we should also consider how we are going the tag those containers as well.
 
Troy
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel



--
Mohammed Zeeshan Ahmed
Associate Software Engineer, Redhat Developers Team (Devtools)

RED HAT | DIFFERENT FOR THE SAKE OF BETTER TECHNOLOGY

Find out why every airline, telecom, commercial bank, healthcare, and financial data services company in the Fortune 500 relies on Red Hat.

Trusted | Red Hat