shawn-hurley
commented
5 years ago How to handle breaking changes in controller-runtime APIs introduced by controller-runtime contributors or by breaking changes in dependencies (e.g. k8s.io/client-go)
There was the potential talk of a generic library that does not depend on k8s.io/api or k8s.io/apimachinery in the apimachinery sig meeting. I would like to explore if we could either help with this work or do this work? I think this would be very helpful for everyone. @DirectXMan12 Have you seen anything more about this?
This would allow us to not have to follow kubernetes release IIUC and allow this library and others to have their own release's. We may still want a compatibility matrix if something drastically changes in the underlying library but I think this might be the place to spend our cycles?
What do folks think?
DirectXMan12
sttts
fejta-bot
At the community meeting on 9/11/2019, there was a discussion about how to version controller-runtime to handle scenarios around dependency changes:
My understanding of semver is that we need to only consider the first scenario when choosing a version number after dependency changes.
My two cents - if the controller-runtime API changes are backwards-compatible, I'm not sure it makes sense to try to ALSO consider compatibility of all transitive dependencies -- that's what the version numbers of the transitive dependencies are for.
If we want to be helpful, we could add a statement to the release notes when we update dependencies to let users know that they might require code changes if they're using those dependencies directly.
With these scenarios in mind, I'd propose a slight change to the versioning scheme while we're pre-1.0:
post-1.0, I would propose:
Thoughts?
/cc @DirectXMan12 @shawn-hurley @justinsb @droot