I'd like to provide some architectural feedback that is worth considering in these cases. Because staging repos are part of the kubernetes/kubernetes core repository, any code placed there is subject to the exact same strict policies that govern the core repo. This includes our rules around cherry-picking, release cycles, and how breaking changes are handled.
Depending on your long-term goals for this library, you should consider the following:
- If the goal is to offer a stable, easily consumable library: It would be much better to handle this out-of-tree (e.g., as a standalone repository). This allows the library to maintain its own independent release cadence, semantic versioning, and stability guarantees without being bound to the Kubernetes core release cycle.
- If the goal is to offer a tightly coupled wrapper: Staging could make sense, but only if end-users are fully prepared to deal with breaking changes and the necessity of bumping their versions in lockstep with Kubernetes core releases.