The canonical import for json-patch v4 is
gopkg.in/evanphx/json-patch.v4 (see
https://github.com/evanphx/json-patch/blob/master/README.md#get-it for
reference).
Using the v4-specific path should also reduce the risk of unwanted v5
upgrade attempts, because they won't be offered as automated upgrades
by dependency upgrade management tools, and they won't happen through
indirect dependencies (see
https://github.com/kubernetes/kubernetes/pull/120327 for context).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 5300466a5c8988b479a151ceb77f49dd00065c83
Clarifies that requesting no conversion is part of the codec factory, and
future refactors will make the codec factory less opionated about conversion.
Kubernetes-commit: 7f9dfe58f4cbe1e1b9e80f52addff70bac87bed4
apps/v1betaX inadventertently contains its own variant of Scale. In
order to support scaling Deployments, ReplicaSets, etc, we need to support
these versions of Scale as well.
Kubernetes-commit: 2c9fc432947bedb2fffc12faf7fc0ee1d0ceffd9
This introduces a polymorphic scale client capable of operating against
scale subresources which return different group-versions of Scale. The
scale subresources may be in group-versions different than the scale
itself, so that we no longer need a copy of every scalable resource in
the extensions API group.
To discovery which Scale group-versions go to which subresources,
discovery is used.
The scale client maintains its own internal versions and conversions to
several external versions, with a "hub" version that's a copy of the
autoscaling internal version.
It currently supports the following group-versions for Scale subresources:
- extensions/v1beta1.Scale
- autoscaling/v1.Scale
Kubernetes-commit: d61a2d90372c301dd11088df8941acf2bb01c38c