Update releasing.md with Kubernetes release process #10709
Conversation
|
cc @alex-mohr @brendandburns for people who have actually done releases recently enough. cc @jbeda because maybe he's bored and might be amused to see his ancient bug closed. cc @eparis for general release process awesomeness. |
|
GCE e2e build/test failed for commit 345a95f7c3c87f3a77c8fcdbb18423ed6695fe6b. |
| You should progress in this strict order without interleaving pieces of each | ||
| major step unless you are very familiar with the release process. | ||
|
|
||
| ### Building a New Major/Minor Version (`vx.y.0`) |
There was a problem hiding this comment.
I've got all sorts of minor nits i'll keep to mymeself, but I do like capital X and Y, to make it easier to distinguish the v...
There was a problem hiding this comment.
Fixed. Feel free to drop in the minor nits, if you want. Though a large goal of this document is "something is better than nothing." And really, "something is better than 2 things", because #1883 and releasing.md were both acting as semi-canonical sources.
| #### Writing Release Notes | ||
|
|
||
| Release notes for a patch release are fast. You just did all the cherry-picks by | ||
| squashing pull requests, so you have the PR #'s in `git log |
There was a problem hiding this comment.
There better not have been any squashing done. Can we pick a different word?
There was a problem hiding this comment.
I was trying to describe what git cherry-pick -m does, which is kind of a weird beast. It picks up the merge pull and patches in the resulting diff, which I think is a better/less-error-prone cherry-pick procedure than individual commit cherry-picks (because a pull request on master might've brought in several commits), but it's a squashed commit of sorts. I'll try to reword that.
zmerlynn
force-pushed
the
i1883
branch
2 times, most recently
from
53e5800 to
165096b
Compare
|
GCE e2e build/test passed for commit 5d76e7373c0770cc041e64aa67b58054308e3517. |
|
LGTM |
|
GCE e2e build/test passed for commit 165096bfe7842c208481ef05e4de5b1c723909d4. |
|
@eparis: Thanks for the review! Over to @alex-mohr for another and ok-to-merge. (And I'm blocked on #10687.) |
|
Note that #10730 discusses revising the cherry-pick process and section of this document, but please review ignoring that. (I'll submit a separate PR on top of this.) |
| When cutting a major/minor release, your first job is to find the branch | ||
| point. We cut `vX.Y.0` releases directly from `master`, which is also the the | ||
| branch that we have most continuous validation on. Go first to [the main GCE | ||
| Jenkins end-to-end job](go/k8s-test/job/kubernetes-e2e-gce) and next to [the |
There was a problem hiding this comment.
GitHub treats these two go links as relative links to the branch. Can you put http:// in front of them?
alex-mohr
added
the
lgtm
|
GCE e2e build/test failed for commit 2aa127a54325b2a72b8fca3a58fc489d8358d556. |
|
GCE e2e build/test passed for commit 95c931b8132db9c87e557060c50fa40381e4ab28. |
|
GCE e2e build/test passed for commit fe8527f2555db499ebb0e9dfba5d0aa955860d8e. |
|
LGTM, happy to ok-to-merge if deps are in. |
|
GCE e2e build/test passed for commit 5e75519d02b18408fd9e8bcbcbf9016910965b16. |
|
TBD: It's late, just leaving a note to myself to update the release documentation that you basically need a full dev environment to run |
|
@zmerlynn, is this ok to merge? |
|
Not yet. I need to redrive #10687 (sigh). |
|
GCE e2e build/test passed for commit be3d5329e618ab857c0549a7fa7a4d1ff7a09f0c. |
This updates releasing.md with actual instructions on how to cut a release, leaving the theory section of that document alone. Along the way, I streamlined tiny bits of the existing process as I was describing them. The instructions are possibly pedantic, but should be executable by anyone at this point, versus taking someone versant in the dark arts. Relies on kubernetes#10910. Fixes kubernetes#1883.
zmerlynn
force-pushed
the
i1883
branch
2 times, most recently
from
5350ec6 to
9c1d2fc
Compare
|
I've updated this documentation to the most current state, and included a short document on the cherry pick process. It is now up to date to the best of my knowledge, and there are probably some gaps where I have the last piece of tribal knowledge somewhere (like why |
|
cc @alex-mohr for review, let's close this. |
|
GCE e2e build/test passed for commit a55ace3796c097c4e95297d33de83d7463792697. |
|
GCE e2e build/test passed for commit 5350ec63c525d9034df2cdc67d00ecdf4befc0f9. |
|
GCE e2e build/test passed for commit 9c1d2fcb0260564eb03e1be12e167ce9e223c531. |
|
GCE e2e build/test passed for commit caa877e. |
|
cc @rjnagal to merge. |
Update releasing.md with Kubernetes release process
|
How did this get merged? It should have broken the build. It fails gendocs. |
|
@bgrant0607: It was green at the time of merge, so it's not clear. We didn't get the right signal. |
|
It was all green when I merged. Do we need to revert? |
|
There's a fix in #11073 |
Update releasing.md with Kubernetes release process
This updates releasing.md with actual instructions on how to cut a
release, leaving the theory section of that document alone. Along the
way, I streamlined tiny bits of the existing process as I was
describing them.
The instructions are possibly pedantic, but should be executable by
anyone at this point, versus taking someone versant in the dark arts.
I also added a tiny instruction to
mark-new-version.shto cry forhelp if you see no diff to master in the backmerge step, because
it's an issue we've seen a couple of times now.
Relies on
#10687#10910. Fixes #1883.