bottlerocket-update-operator icon indicating copy to clipboard operation
bottlerocket-update-operator copied to clipboard

Bump k8s-openapi from 0.14.0 to 0.16.0

Open dependabot[bot] opened this issue 3 years ago • 0 comments

Bumps k8s-openapi from 0.14.0 to 0.16.0.

Release notes

Sourced from k8s-openapi's releases.

v0.16.0

k8s-openapi

  • BREAKING CHANGE: Added support for Kubernetes 1.25 under the v1_25 feature.

  • FEATURE: All spec types now implement a deep-merge API via a DeepMerge trait impl with a fn merge_from(&mut self, other: Self) method. This is useful for builder-like operations.

Corresponding Kubernetes API server versions:

  • v1.18.20
  • v1.19.16
  • v1.20.15
  • v1.21.14
  • v1.22.14
  • v1.23.11
  • v1.24.5
  • v1.25.1

k8s-openapi-codegen-common

  • No changes.

k8s-openapi-derive

  • BREAKING CHANGE: #[derive(CustomResourceDefinition)] no longer generates a list type alias. For example, when applied to struct FooSpec, previously the custom derive would generate pub type FooList = k8s_openapi::List<Foo>; It no longer does this, in accordance with the main k8s-openapi crate where such aliases were removed back in v0.7.0

  • FEATURE: The generated custom resource type will implement k8s_openapi::DeepMerge if the impl_deep_merge custom derive attribute is used. Note that this requires you to implement k8s_openapi::DeepMerge on the spec type yourself; the custom derive does not do that.

v0.15.0 (2022-05-22)

k8s-openapi

  • BREAKING CHANGE: The pretty optional parameter has been removed from all operations. Setting this parameter to true would've made the API server pretty-print the JSON response, which is meaningless for a programmatic client.

  • BREAKING CHANGE: In addition to the previous change, the exact and export parameters have been removed from all read operations (eg Pod::read_namespaced_pod). These parameters were removed in Kubernetes v1.21 and were known to be broken before that, and would've caused the server response to not be able to be parsed correctly via the operation's response type anyway.

    All read operations with the exception of Pod::read_namespaced_pod_log had only these three optional parameters, so now that they've been removed such read operations don't have an optional: ReadFooOptional<'_> parameter at all.

  • BREAKING CHANGE: Operation names no longer include the _namespaced part and the resource type name. For example, Pod::read_namespaced_pod is now just Pod::read. The corresponding optional parameters type and response type no longer include the Namespaced part, eg ReadNamespacedPodResponse is now just ReadPodResponse.

  • BREAKING CHANGE: Added support for Kubernetes 1.24 under the v1_24 feature.

  • BREAKING CHANGE: Dropped support for Kubernetes 1.16 and 1.17.

  • FEATURE: The K8S_OPENAPI_ENABLED_VERSION env var can now be set at build time to enable a specific API version, just like enabling a specific version feature would've done. This is only meant to be used by library developers who want to run cargo check, cargo doc, etc commands, for which the previous advice of enabling a version feature via a dev dependency would not work.

Corresponding Kubernetes API server versions:

  • v1.18.20
  • v1.19.16
  • v1.20.15

... (truncated)

Changelog

Sourced from k8s-openapi's changelog.

v0.16.0 (2022-09-15)

k8s-openapi

  • BREAKING CHANGE: Added support for Kubernetes 1.25 under the v1_25 feature.

  • FEATURE: All spec types now implement a deep-merge API via a DeepMerge trait impl with a fn merge_from(&mut self, other: Self) method. This is useful for builder-like operations.

Corresponding Kubernetes API server versions:

  • v1.18.20
  • v1.19.16
  • v1.20.15
  • v1.21.14
  • v1.22.14
  • v1.23.11
  • v1.24.5
  • v1.25.1

k8s-openapi-codegen-common

  • No changes.

k8s-openapi-derive

  • BREAKING CHANGE: #[derive(CustomResourceDefinition)] no longer generates a list type alias. For example, when applied to struct FooSpec, previously the custom derive would generate pub type FooList = k8s_openapi::List<Foo>; It no longer does this, in accordance with the main k8s-openapi crate where such aliases were removed back in v0.7.0

  • FEATURE: The generated custom resource type will implement k8s_openapi::DeepMerge if the impl_deep_merge custom derive attribute is used. Note that this requires you to implement k8s_openapi::DeepMerge on the spec type yourself; the custom derive does not do that.


v0.15.0 (2022-05-22)

k8s-openapi

  • BREAKING CHANGE: The pretty optional parameter has been removed from all operations. Setting this parameter to true would've made the API server pretty-print the JSON response, which is meaningless for a programmatic client.

  • BREAKING CHANGE: In addition to the previous change, the exact and export parameters have been removed from all read operations (eg Pod::read_namespaced_pod). These parameters were removed in Kubernetes v1.21 and were known to be broken before that, and would've caused the server response to not be able to be parsed correctly via the operation's response type anyway.

    All read operations with the exception of Pod::read_namespaced_pod_log had only these three optional parameters, so now that they've been removed such read operations don't have an optional: ReadFooOptional<'_> parameter at all.

  • BREAKING CHANGE: Operation names no longer include the _namespaced part and the resource type name. For example, Pod::read_namespaced_pod is now just Pod::read. The corresponding optional parameters type and response type no longer include the Namespaced part, eg ReadNamespacedPodResponse is now just ReadPodResponse.

  • BREAKING CHANGE: Added support for Kubernetes 1.24 under the v1_24 feature.

  • BREAKING CHANGE: Dropped support for Kubernetes 1.16 and 1.17.

  • FEATURE: The K8S_OPENAPI_ENABLED_VERSION env var can now be set at build time to enable a specific API version, just like enabling a specific version feature would've done. This is only meant to be used by library developers who want to run cargo check, cargo doc, etc commands, for which the previous advice of enabling a version feature via a dev dependency would not work.

Corresponding Kubernetes API server versions:

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependabot[bot] avatar Oct 13 '22 15:10 dependabot[bot]