You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past we have used a release process based on git merge. However, with the inclusion of GHMQ, this is no longer possible. Thus, the instructions regarding cutting a new release should be updated accordingly.
Solution you'd like
Add/change a few points in the release process to match the current situation, notably:
Use git checkout stable && git merge --ff-only master to update the stable branch, which should always contain a subset of master's commit history.
Update the commit shasum in rustup-init.sh not in the release PR, but in a dedicated consequent PR right before tagging.
This commit shasum is the one right before the release. When we were using git merge it used to point to the exact commit bumping the version in Cargo.lock, but since the master history is linear now (meaning a new version will appear earlier on master than on stable, which is indeed the case for many other projects), it should be clearer if we point it to the commit finalizing the CHANGELOG instead (cf. 1.27.0 release planning #3501 (comment)).
Tag the release onto the latest stable commit.
How beta-testing works in Rustup via the dev environment, and when exactly to inform t-release.
@brettearle The team is currently focusing on shipping a new release and thus we are still experimenting and don't yet know what to change precisely. I'll handle this issue myself when we're done with release 1.27. Many thanks anyway! 🙇
PS: Thanks again for the other PRs you've made recently! I plan to merge them after 1.27 as well, please stay tuned!
Problem you are trying to solve
In the past we have used a release process based on
git merge
. However, with the inclusion of GHMQ, this is no longer possible. Thus, the instructions regarding cutting a new release should be updated accordingly.Solution you'd like
Add/change a few points in the release process to match the current situation, notably:
git checkout stable && git merge --ff-only master
to update thestable
branch, which should always contain a subset ofmaster
's commit history.rustup-init.sh
not in the release PR, but in a dedicated consequent PR right before tagging.git merge
it used to point to the exact commit bumping the version inCargo.lock
, but since themaster
history is linear now (meaning a new version will appear earlier onmaster
than onstable
, which is indeed the case for many other projects), it should be clearer if we point it to the commit finalizing theCHANGELOG
instead (cf. 1.27.0 release planning #3501 (comment)).stable
commit.dev
environment, and when exactly to informt-release
.Notes
Closes #3501.
The text was updated successfully, but these errors were encountered: