Include more information on updating versions and workspace publishing #7192
Conversation
documents/process/release.md
Outdated
| * [ ] For utils that have had substantiative changes (new APIs, etc), update them in `workspace.dependencies`. When unsure, just update. | ||
| * [ ] Get this PR reviewed and checked in. | ||
| * [ ] Perform the release. | ||
| * The best way to do this is to use `cargo workspaces publish --from-git`. |
There was a problem hiding this comment.
Is this obsolete? There seems to be a new --workspace option on cargo publish
There was a problem hiding this comment.
No idea. Haven't tried it.
documents/process/release.md
Outdated
| * [ ] Get this PR reviewed and checked in. | ||
| * [ ] Perform the release. | ||
| * The best way to do this is to use `cargo workspaces publish --from-git`. | ||
| * If the release fails at some point and needs a fix, make a new commit for the fix. After a full successful release, make a PR with these commits and merge it with a merge commit. You may need to temporarily change branch protection rules. |
There was a problem hiding this comment.
so here I disagree. what we should have done is make a normal squash PR, and continue with the release once the PR has been merged
There was a problem hiding this comment.
This happens multiple times in a release and we should not be waiting for that IMO. Especially if we want to handle the "dirty working tree" problem around dev-deps (#7196)
There was a problem hiding this comment.
yes we should. if there are two people working on a release and you're not blocked on approval it takes ~10 minutes to run CI
There was a problem hiding this comment.
The "dirty working tree" will happen ~10 times per release, if we decide to care about it.
That's a lot of sync time.
Is your goal here to avoid releasing something that breaks CI? I think that's reasonable, for actual changes we should probably not push to main. But I also think the release driver should be allowed to merge them without review.
For cargo publish dev dep changes I do not think we should be doing this. In that case we should push directly, because ideally it's a commit that doesn't actually change anything (it removes a dev-dep which gets immediately added back).
There was a problem hiding this comment.
I clarified this. I also figured out a process for us to still use workspaces publish without dirtying the tree.
fea3651 to
9c44deb
Compare
Co-authored-by: Robert Bastian <4706271+robertbastian@users.noreply.github.com>
9c44deb to
8754ef4
Compare
cargo workspaces publish --from-gitworks quite well and we should emphasize it more.Also included substeps for version updating around dependency updates that ought to avoid problems like #7191.