Add client-go 6.0.0 changelog

[nikhita]

Ref: https://docs.google.com/spreadsheets/d/1PahRDTfiPbD1DEjtL-3ButW3U-FTKzS8r9NKZQ2kr2c/edit#

/cc @sttts @caesarxuchao @munnerz @timoreimann @markmandel

[k8s-ci-robot]

@nikhita: GitHub didn't allow me to request PR reviews from the following users: timoreimann, markmandel.

Note that only kubernetes members can review this PR, and authors cannot review their own PRs.

In response to this:

Ref: https://docs.google.com/spreadsheets/d/1PahRDTfiPbD1DEjtL-3ButW3U-FTKzS8r9NKZQ2kr2c/edit#

/cc @sttts @caesarxuchao @munnerz @timoreimann @markmandel

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-reviewable]

This change is 

[caesarxuchao]

Great job @nikhita!

I guess you plan to do the following modifications anyway, but it doesn't hurt if I type too much :)

• Can we categorize the entries into three categories, "Breaking changes", "New features", "Bug fixes and improvements"?
• In each category, can we gather the k8s.io/apimachiner and k8s.io/api changes and prefix their entries with the repo name, e.g.,
  • [k8s.io/apimachinery] ObjectCopier interface was removed

[caesarxuchao]

How about "Certificate manager was moved from kubelet to client-go"?

[caesarxuchao]

This is new feature.

[caesarxuchao]

new feature

[caesarxuchao]

Bug fix

[caesarxuchao]

Breaking change. Swagger 1.2 retriever was removed from the discovery client.

[caesarxuchao]

Bug fix. Maybe "Unset creationTimestamp field is output as null if encoded from an unstructured object."

[caesarxuchao]

Improvement.

[caesarxuchao]

It seems to not contain any code change. Remove it?

[nikhita]

This could be useful for the users since it adds a new tag. WDYT?

[caesarxuchao]

I think that it belongs to the k8s.io/code-generator changelog. Unlike k8s.io/apimachiner or k8s.ioo/api, users of client-go doesn't have to learn code-generator.

[caesarxuchao]

Breaking change, although the broken API was in alpha.

[caesarxuchao]

Breaking change. Actually we should say AppsV1() or Apps() interface.

[caesarxuchao]

Can we add an action-required notice in the changelog saying that clientset's default versioned group interface (like https://github.com/kubernetes/kubernetes/blob/f875ee596d4eb0d5847cf2f0e6b13a80de7d6008/staging/src/k8s.io/client-go/kubernetes/clientset.go#L58-L59) will be removed in next release.

[nikhita]

Should this go as a note for the next release or should it be included for this one? Since the removal will be done for the next one.

Makes sense to have it here as well, but just wanted to double check.

[caesarxuchao]

You're right. Adding it as a note for the next release is better.

[markmandel]

I can't review this (which is fine), but I ❤️ the suggestions @caesarxuchao is putting forward. Will make it much easier for developers to see what is happening!

[timoreimann]

This may be a silly question: what's the purpose of marking where a PR comes from (e.g., apimachinery), especially for the end user reading the changelog?

Moreover, what's the reason actually that we are noting down changes from those other repositories in the client-go repository? Shouldn't they belong in their respective repository change logs?

There's a chance I'm asking all of these questions because I'm not super familiar with the relationship between client-go, apimachinery, api, and possibly other related repositories eventually needed for a Kubernetes client. From a pure FOSS and Github perspective, however, it seems odd to me that the changelog refers to changes which are beyond the scope of the repository hosting the changelog.

[nikhita]

Thanks for comments, @caesarxuchao! :)

I have addressed most of the comments and left a couple of questions.

[sttts]

Swagger 1.2 retriever DiscoveryClient.SwaggerSchema was removed...

[nikhita]

Done.

[caesarxuchao]

@timoreimann k8s.io/client-go depends on k8s.io/apimachinery and k8s.io/api, so changes in those two repos affect client-go users. We can create changelogs in those two repos, and add links to them. @sttts @nikhita WDYT?

[sttts]

k8s.io/client-go depends on k8s.io/apimachinery and k8s.io/api, so changes in those two repos affect client-go users. We can create changelogs in those two repos, and add links to them. @sttts @nikhita WDYT?

I would like to avoid complication and keep at least api and apimachinery changes in the client-go release notes. I have no strong opinion about code-generator.

[timoreimann]

@sttts how about leaving a short note then on the relationship between the projects? Basically just what @caesarxuchao said to help users not familiar with the associated repositories.

I could do a quick commit if we agree.

[nikhita]

How about creating a changelog for code-generator in it's own repo and adding notes there? Since code-generator doesn't affect client-go, I think we can avoid to mention it here.

[caesarxuchao]

Ok. @nikhita could you add an explanation in the release note on why we include the apimachinery and api entries?

How about creating a changelog for code-generator in it's own repo and adding notes there? Since code-generator doesn't affect client-go, I think we can avoid to mention it here.

Agree.

[nikhita]

@nikhita could you add an explanation in the release note on why we include the apimachinery and api entries?

Will do.

[caesarxuchao]

Could you sort the entries in "Breaking Changes", so that the client-go ones go first, then the [k8s.io/api] ones, and then the [k8s.io/apimachinery] ones? Same for the "New features" and "Bugs and Improvements" sections.

[nikhita]

Done.

[sttts]

duplicate

[nikhita]

Removed.

[sttts]

... For that the kinds have changed completely and old code must be ported to admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration and ValidatingWebhookConfiguration.

[nikhita]

Done.

[sttts]

... to k8s.io/client-go/util/certificates.

Can we sort this list according to importance? This is just a util package, not really of high prio.

[nikhita]

Can we sort this list according to importance?

This would destroy consistency with the order: client-go, api and apimachinery.

[sttts]

Workloads api types are promoted to apps/v1

[nikhita]

Done.

[sttts]

Added polymorphic scale client in k8s.io/client-go/scale, which ...

[nikhita]

Done.

[sttts]

this is a breaking change for the section above.

[nikhita]

Moved.

[sttts]

this is a breaking change technically.

[nikhita]

Moved.

[sttts]

I think we can drop all changes but the one about DefaultHardPodAffinitySymmetricWeight. IMO we should only list really important bug fixes. What do you think?

[nikhita]

IMO we should only list really important bug fixes. What do you think?

👍

With DefaultHardPodAffinitySymmetricWeight moved to breaking change, we would have no bug fixes and improvements.

[nikhita]

@nikhita could you add an explanation in the release note on why we include the apimachinery and api entries?

Done.

[nikhita]

How about creating a changelog for code-generator in it's own repo and adding notes there? Since code-generator doesn't affect client-go, I think we can avoid to mention it here.

@sttts Which version of code-generator would this be?

[munnerz]

I'm not 100% convinced that all the release notes should end out in a single repo (client-go). Perhaps we can aggregate into client-go, but I think the sub-repos should also contain things specifically related to them in some way. If not, then simply in k/k might make most sense.

That said, having them all in one place is important as most people when they first start consuming these libs won't have the conceptual overview of how these projects relate, so definitely having a single aggregated changelog somewhere makes sense.

This really does relate to the discussions about whether client-go should include all these extra tools that it currently does to be honest. It's a mixture of generated and non generated code, which is a bit confusing. In my mind, client-go should really just be a product of the generators in code-generator, and we'd have some separate client-go-tools or the like. But maybe I'm looking at this from a 'purist' standpoint that makes sense once you've gotten familiar with the repos but not so much for an outsider 🤔

[munnerz]

(just to clarify, I don't think what I'm saying above should block this PR being merged. It's important that these changes are documented, and right now client-go is where we store a lot of code related to api extensions)

[nikhita]

I think the sub-repos should also contain things specifically related to them in some way.

Reminds me that apiextensions-apiserver also needs a CHANGELOG then.

@sttts Again, what version naming would we use for apiextensions-apiserver?

[sttts]

Which version of code-generator would this be?

@nikhita we will put it on the kubernetes-1.9.0 tag I would suggest. Wdyt?

[sttts]

Again, what version naming would we use for apiextensions-apiserver?

We could also re-use the kubernetes-1.9.0. I hesitate to introduce other tags as well as this might get more and more confusing with semver in client-go and non-semver elsewhere.

[nikhita]

we will put it on the kubernetes-1.9.0 tag I would suggest. Wdyt?

Sgtm.

I hesitate to introduce other tags as well as this might get more and more confusing with semver in client-go and non-semver elsewhere.

👍 👍 👍

[nikhita]

I'll create a CHANGELOG for those repos as well.

[nikhita]

Any further changes need to be made here?

[nikhita]

For apiextensions-apiserver: kubernetes/kubernetes#57206.

[sttts]

/lgtm
/approve no-issue