search

openshift / cluster-operator

52 stars 35 forks source link

Tags and releases? #335

Open jhernand opened 6 years ago

jhernand commented 6 years ago

We have an application that includes the cluster operator as one of its components. Currently, in order to be able to have reproducible deployments of this application, we have a clone of this git repository where we add our own tags. From those tags we build our own versioned images, like cluster-operator:v0.0.3, cluster-operator:v0.0.4, etc. When then use those versioned images to do reproducible deployments to our production environments. We would like to stop doing that, and use instead stable versions released by the cluster operator project. Is there any plan to have those stable releases? Will you use tags to handle them? Will the images that you publish be versioned as well?

jhernand commented 6 years ago

CC: @kbsingh, @oourfali, @zgalor, @nimrodshn.

dgoodwin commented 6 years ago

Yes I would expect we would push stable release tags and images. I'd like to tie in as much as possible to the automated release team's tooling to do this for us, but I'm still coming up to speed on it.

Have you considered using git hashes in your tags, assume v0.0.1 is a constant and just append the short git hash? This should eliminate the need for a cloned repo.

jhernand commented 6 years ago

Using a cloned repo is more a convenience than a need. We could just keep the association between our v0.0.1 version and the git hash of this repo, as a suffix as you suggest, or storing it somewhere. But the real problem is that we would still be deciding ourselves what is an stable release of the cluster operator. We don't want to do that, we prefer to rely on what you decide.

dgoodwin commented 6 years ago

That would be ideal, unfortunately I am not sure when we will be able to deem anything stable, probably some time away. In meantime I would suggest tagging your images somehow to indicate they are pre-0.0.1. Some minor risk if we end up with multiple cluster-operator:v0.0.1 images floating around that contain different things.

jhernand commented 6 years ago

Makes sense, we will add some prefix or suffix to the tag to make sure that there are no conflicts. Something like my-v0.0.1 or v0.0.1.my. Anyhow conflict is unlikely, as we use a different image repository.

Do you have any ETA for a first stable release? A few weeks? A few months?

dgoodwin commented 6 years ago

I think it's safe to say months, we're a but scattered atm working on other things for 4.0 and getting ready so we can consume the new installer.