Closed Jefftree closed 6 months ago
Possibly third solution:
go get -u
will only update within the branch.No? I think that'd be fairly simple to do, am I missing something?
Possibly third solution:
- Version kube-openapi like kubernetes: we have a new branch for each version of kubernetes/client-go. In between release we can change compatibility if we want. Running
go get -u
will only update within the branch.No? I think that'd be fairly simple to do, am I missing something?
This was part of the second solution but I'll edit to make it more clear. I'll list a couple of drawbacks to this approach that we get for free if kube-openapi becomes a staging repo
v0.27-20230824-xxxxxx
which would need to be flipped to v0.28
kube-openapi once 1.28 is released for k/k). gomod works off of tags and not branches, so we'll still need commit numbers and stuff./cc @alexzielenski @sttts @liggitt
even if we wanted to make k8s.io/kube-openapi a staging repo (I wouldn't), we can't make k8s.io/kube-openapi a staging repo as long as k8s.io/kubernetes has dependencies that reference it.
k8s.io/kubernetes → non-staging dep → staging dep
is not allowed, since it would make it impossible to modify the staging dep in a way the non-staging dep would have to react to
I am curious which parts of this repo ppl actually use.
I have considered kube-openapi always as an internal repository without any guarantee (created to increase development velocity). And I think most of the code is written in a style that does not expect reuse in other places. In other words, semver would be cosmetics, but not honest. Semver where we constantly increase the major version has no use.
So if we want to make progress here, we should go package by package and check use outside of kube and then do a decision package by package.
Note, and this is crucial for this repo, kube-openapi has a collection of very different functionality that is independently developed. Our go-openapi fork is very different from pkg/cached or pkg/builder. Semver for a collection repository like this is not a good strategy. We could apply semver to individual parts via nested go.mods. That would make a lot more sense.
Right, so the problem is mostly that whatever is pulled by client-go is problematic. But I'm a little concerned about the package-per-package policy inside the repo. But you're right, only the packages that are pull by client-go are problematic.
Note, and this is crucial for this repo, kube-openapi has a collection of very different functionality that is independently developed. Our go-openapi fork is very different from pkg/cached or pkg/builder. Semver for a collection repository like this is not a good strategy. We could apply semver to individual parts via nested go.mods. That would make a lot more sense.
Agreed with this.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
kube-openapi has always been on the v0 revision with importers pointing go.mod files directly at a specific revision (eg:
kube-openapi v0.0.0-20230717233707-2695361300d9
). By being on the v0 revision system, we can iterate quite fast and have no compatibility guarantees for breaking changes. I think this repo has got to the point where we should reconsider our versioning system.Recently we've had issues such as https://github.com/kubernetes/client-go/issues/1269 involving a breaking change that affects quite a large number of clients. kube-openapi used to only be a dependency of k/k in which kube-openapi versions were in lockstep with k/k versions. With an additional client-go dependency, the lockstep is not guaranteed, and forcing it (eg: by asking users not to run
go get -u
) is not great user experience. The main problem is that pre-release/development versions of kube-openapi get captured by older versions of client-go.We have 900+ indirect dependencies on the repo (most via client-go) and 90+ direct dependencies on the repo (mostly openapi-gen or proto), and this will probably grow with more validation components being added in
Most updates to this repo directly affect k/k and a follow up PR is created as a version bump to k/k. For many PRs, the reviewer would ask to see the k/k diff (tests, diff in openapi spec, etc) before approving the kube-openapi PR anyway. Especially with multiple rounds of reviews, it becomes difficult to tell whether the k/k PR has synced with the latest kube-openapi PR changes. It would be great if we can improve this process.
Iteration frequency is big pro for having kube-openapi's own cadence of releases. However, we are quite locked into k/k's release cadence as almost all the code is a dependency for k/k. Every bump to kube-openapi always results in a bump to k/k. The more changes we bundle up before bumping k/k, the higher the likelihood of them causing problems.
With all that, here are a few suggestions
go get -u
.