Re: openshift/api and openshift/client-go are authoritative

2017-12-05 Thread Ben Parees
On Tue, Dec 5, 2017 at 4:13 PM, Simo Sorce  wrote:

> 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 ?
>

"bump(*)"

I got to be the guinea pig on this, so you can see my prs here:

changed the api:
https://github.com/openshift/api/pull/10

bumped the client-go deps:
https://github.com/openshift/client-go/pull/12

trying to bump the origin deps so i can actually make the change i care
about:
https://github.com/openshift/origin/pull/17314/commits/fc47ea3baba0631ba84e82a80a98c10670dabbd8




>
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>



-- 
Ben Parees | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


openshift/api and openshift/client-go are authoritative

2017-11-28 Thread David Eads
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.
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev