On Tue, 2017-11-28 at 13:58 -0500, David Eads wrote: > As of https://github.com/openshift/origin/pull/17477, h > ttps://github.com/openshift/api and https://github.com/openshift/client-go are > the authoritative source of the OpenShift API types and the OpenShift > external clients. The external types and go client are no longer present > in https://github.com/openshift/origin. This makes it possible to interact > with an OpenShift cluster without trying to vendor openshift/origin and it > changes the way that API changes are merged. > > To make an API change in 3.8+: > > 1. open a pull with the external types to openshift/api and get it > reviewed, approved, and merged > 2. bump the vendored dependencies in openshift/client-go, regenerate > (make generate build), and get it merged. > 3. bump the vendored dependencies in openshift/origin > (hack/update-deps.sh), update your internal types, and start serving your > new API. > > For forks, you will have to merge into the appropriate branches of the > various repositories.
SoI have to deal with this now. Looking at the api repository I see you opened commits with titles like this: UPSTREAM: openshift/origin: missed tags I do not understand, if the api repository is authoritative, then this repository is upstream, not openshift/origin Is there a convention we need to follow for the vendoring of api into client-go and origin as far as naming commits ? Care to provide an example/template ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
