Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates the release CI workflow to enhance automation and better align with the release process for downstream repos.
Release flow:
origin/dev
to the commit associated with the latest upstream release, cherry-pick the patch commits and CI changes previously ondev
, and force-push todev
.release/aptos-node-<version>-patched
branch todev
, which simply increments the version number in some metadata file e.g.PATCH_RELEASE.md
(since this repo doesn't use Cargo versioning). The purpose of this is to 1. Create a minimal PR to solicit CI & review feedback, and 2. to create therelease/*
branch as a permanent artifact to be used as the source of the release.release/
branch as a patched version of the upstream release. NOTE: Do not delete therelease/
branch after it's been merged todev
, as it will be a load-bearing dependency for downstream crates and the base for future hotfixes.Hotfix flow:
release/aptos-node-<version>-patched
calledhotfix/aptos-node-<version>-patched
.origin
.hotfix
input and the same version as before. This will create a PR containing both the hotfixes and thePATCH_RELEASE.md
version bump, with therelease/
branch of the same version as the base branch.release/
branch, overwriting the existing release. Thehotfix/
branch can then be deleted as it is no longer needed.Future work:
patch
branch or similar for ease of use (more notes at the end).dev
force push if it's deemed sufficiently secure. The artifacts we want to keep are therelease/*
branches, as well as the patch commits somewhere that can be cherry-picked.hotfix
releases, which overwrite existing versions and could thus potentially break downstream crates if not carefully checked beforehand.Note
Rebase/force-pushing to
dev
on every release is unusual, and mainly used here for consistency with our other release processes (merging release PRs into the default branch) and ease of use. We could instead rebase thedev
patch commits on latest upstream, but this generated numerous merge conflicts with over 100 commits between releases.We could instead keep
dev
as the patch branch and merge releases into aprod
branch or similar, but then there's not much use fordev
being the default branch since continuous development is not expected. Will explore this further.Tested on https://github.com/samuelburnham/aptos-core