docs: document our branching / versioning process #408
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
approved
justinsb
force-pushed
the
branching_and_versioning
branch
from
a0e84c5 to
66d71dd
Compare
|
|
||
| Before beta releases, the master branch is for the next minor version. If we tag a version, it would be (for example) `1.101.0-alpha.1` (and then `1.101.0-alpha.2` etc), assuming the most recent release branch was `1.100` | ||
|
|
||
| TODO: Should we rename master to main now? |
There was a problem hiding this comment.
I removed the two TODOs here, and will track them in an issue. It probably doesn't matter, but I want to think about whether we would tag any releases before or after renaming the branch.
| | kdp version | controller-runtime version | client-go version | | ||
| |---|---|---| | ||
| | v0.20 | v0.20 | v0.32 | | ||
| | v0.19 | v0.19 | v0.31 | | ||
| | v0.18 | v0.18 | v0.30 | | ||
| | ... | ... | ... | | ||
| | v0.x | v0.x | v0.x+12 | |
There was a problem hiding this comment.
I think we should have the versioning scheme allow for releasing multiple kdp versions per controller-runtime/client-go version; easiest is probably just to increment the patch, but we might want to explicitly call that out here.
There was a problem hiding this comment.
I'll try to expand. My 2c is that while in theory we might want to make breaking changes more often than client-go releases, in practice I don't think that's very likely, and I think that would make the library difficult to consume. So agree that we should have multiple patch releases - agree that's not clear. But those patches should avoid breaking changes.
Note that we can still make as many breaking changes as we want on the main branch; we just only release a batch of breaking changes every 4 months or so. (And of course the ideal number of breaking changes is zero :-) )
There was a problem hiding this comment.
I added a small paragraph here to describe this - thanks for the suggestion!
| | v0.x | v0.x | v0.x+12 | | ||
|
|
||
|
|
||
| TODO: Should we align with client-go version? |
There was a problem hiding this comment.
Makes more sense to align with controller-runtime than client-go IMO.
There was a problem hiding this comment.
Yes, I was just wondering whether controller-runtime might reconsider their decision at some point. In any case, we just "go up" by 12 versions if we ever change our mind - not a huge problem (in this direction!)
There was a problem hiding this comment.
I think if we decide to follow controller-runtime and they decide to change their versioning scheme, our decision can stand and we just keep following them :)
There was a problem hiding this comment.
Makes sense - removed the TODO
We want to be more systematic about our branching / versioning. Document the process we were (trying to) follow. We can also automate some of the toil here.
justinsb
force-pushed
the
branching_and_versioning
branch
from
66d71dd to
8530d61
Compare
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb, tomasaschan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
We want to be more systematic about our branching / versioning.
Document the process we were (trying to) follow. We can also
automate some of the toil here.