Skip to content
This repository has been archived by the owner on Jan 28, 2020. It is now read-only.

Tags and releases? #335

Open
jhernand opened this issue Sep 6, 2018 · 6 comments
Open

Tags and releases? #335

jhernand opened this issue Sep 6, 2018 · 6 comments

Comments

@jhernand
Copy link
Contributor

jhernand commented Sep 6, 2018

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
Copy link
Contributor Author

jhernand commented Sep 6, 2018

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

@dgoodwin
Copy link
Contributor

dgoodwin commented Sep 6, 2018

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
Copy link
Contributor Author

jhernand commented Sep 6, 2018

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
Copy link
Contributor

dgoodwin commented Sep 6, 2018

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
Copy link
Contributor Author

jhernand commented Sep 6, 2018

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
Copy link
Contributor

dgoodwin commented Sep 6, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants