docs(dev-guide): update release process with new backporting flow#4805
docs(dev-guide): update release process with new backporting flow#4805rami3l merged 2 commits intorust-lang:mainfrom
Conversation
rami3l
force-pushed
the
docs/new-release-flow
branch
5 times, most recently
from
2b53b21 to
1a554cc
Compare
| - A major incompatibility has been introduced in this release: | ||
| increment the _major_ number instead. |
There was a problem hiding this comment.
Hm, this isn't really true in practice though? As noted further down. I know we've had discussions on whether we should or not and even if semver makes sense for binaries.
There was a problem hiding this comment.
@ChrisDenton This is inherited from the previous docs (it's at least the 3rd version since my arrival), and if you all feel okay for removing/adjusting just (this) line I'd love to do that :)
There was a problem hiding this comment.
Thinking about, we should probably leave this to another PR. It might be worth resolving the conversation about semver first.
| Rustup is distributed. Below is a list of things to be done in order to cut a | ||
| new [b]eta release or an official [r]elease: |
There was a problem hiding this comment.
These steps look right to me atm but I usually find the real test is when I actually try following them for real 😉.
There was a problem hiding this comment.
@ChrisDenton I'm actually following those steps (in the previous version) but please feel free to suggest if you have found anything that can be improved on the spot for the new version. Otherwise, as I have suggested, we can merge this first and refine the instructions afterwards.
rami3l
force-pushed
the
docs/new-release-flow
branch
from
1a554cc to
304ffa9
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
rami3l
changed the title
3 participants
Part of #4738.
This flow is not verified yet but I think as long as this passes the vibe check, we can merge it first, and then update it in place as a part of the next
CHANGELOG.mdupdate during the next release if some changes are indeed required.