release process #1327
release process #1327
Conversation
okwme
requested review from
alexanderbez,
zmanian,
yaruwangway,
jgimeno,
crodriguezvega,
cmwaters,
jackzampolin,
mmulji-ic,
glnro and
tokamak-git
as code owners
|
let's make sure that the contents of this PR mirror the description on #1325 |
| ### Branch: `release-prepare` | ||
| The `release-prepare` branch is initially created from the latest `release/vn.0.x` of the previous major release. It serves the same purpose as `main` except for the next planned Cosmos Hub Upgrade. As soon as the upgrade has taken place, it is merged into main and won't exist until the next upgrade is upcoming. During the period that `main` is the currently running network version and a new major release is being prepared, `release-prepare` is targeted for PRs that contain bug-fixes/features/improvements for that release. There may be some PRs that target `main` because they are relevant to the current network, but are also relevant to the upcoming upgrade. These should be cherry picked into `release-prepare` before being subsequently cherry picked into the respective `release/vn.0.x` that is being used for the next upgrade. The `release-prepare` branch aims to be a clean starting point for the subsequent `release` branch. Therefore, only after the binary built from `release-prepare` branch passed dev-testnet action, will this branch be used in a subsequent `release` branch. | ||
|
|
||
| The `release-prepare` branch will become `main` after the relevant Cosmos Hub Network Upgrade successfully takes place. |
There was a problem hiding this comment.
will be merged into main after the relevant ...
| ### Branch: `main` | ||
| The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included in a release that is used on the currently live Cosmos Hub Network or to be backported to a previous release. The PRs against `main` might only be get merged when the release process starts. | ||
|
|
||
| ### Branch: `release` |
RELEASING.md
Outdated
| The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included in a release that is used on the currently live Cosmos Hub Network or to be backported to a previous release. The PRs against `main` might only be get merged when the release process starts. | ||
|
|
||
| ### Branch: `release` | ||
| There are multiple long lived branches with the `release/` prefix. Each release series follows the format `release/vn.0.x`, e.g. `release/v7.0.x`. The branch `release/vn.0.x` should point to the most updated `vn` release, e.g. `release/v5.0.x` should be the same as `release/v5.0.8` if that's the latest `v5.0` release. When starting a new minor or patch release, begin with `release/vn.0.x` and checkout a new branch called `rc0/vn.0.m` where `m` is +1 the latest release number. This branch will be used in a PR into `release/vn.0.m` and eventually merged back to `release/vn.0.x`. When making a major release, the process should be the same as minor and patch except begin with a name like `release/vn.0.0-rc0` which contains cherry-picked commits from `release-prepare` branch or merged from `release-prepare` branch. |
There was a problem hiding this comment.
Assume we can have minor releases within the 3 month time window. Should correct multiple references here.
... release/vn.0.x, e.g. release/v7.0.x -> should be release/v{major}.{min}.{patch}, e.g. release/v7.0.x
References release/vn.0.x are incorrect, as 0 could be 1, 2, 3, ... release/vn.min.x
There was a problem hiding this comment.
We've never really used minor releases before. I've always assumed it's because there is ambiguity around what it means to "add functionality in a backwards compatible manner" with regard to blockchains. The feature can be backwards compatible from an API point of view, but it might not be backwards compatible from a deterministic point of view. In the Cosmos SDK I've seen minor releases that were for security bugs that were non-deterministic and required a coordinated hard fork. These were done without upgrades because often the non-determinism was for situations which had never occured in the history of the blockchain, so would not cause app hash mismatches.
I guess that's a pretty good policy for us as well... something like:
Minor releases only occur for state breaking bug fixes are possible to be used in a coordinated hard fork outside of an on-chain upgrade. These state breaking releases are only possible to be performed during a coordinated hard fork if the non-determinism hasn't been exploited in the history of the chain and the upgrade can be coordinated quickly.
Otherwise what is the reference to 3 months about? Is that how some codebases justify the use of minor? based on a time frame?
There was a problem hiding this comment.
We've had minor releases before in the 4.1.x-4.2.x release lines, hence the comment.
Regarding 3 month cycles, wanted to know when we bump main and minor version numbers -> part of the 3month release cycle or something or a combination?
RELEASING.md
Outdated
| The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included in a release that is used on the currently live Cosmos Hub Network or to be backported to a previous release. The PRs against `main` might only be get merged when the release process starts. | ||
|
|
||
| ### Branch: `release` | ||
| There are multiple long lived branches with the `release/` prefix. Each release series follows the format `release/vn.0.x`, e.g. `release/v7.0.x`. The branch `release/vn.0.x` should point to the most updated `vn` release, e.g. `release/v5.0.x` should be the same as `release/v5.0.8` if that's the latest `v5.0` release. When starting a new minor or patch release, begin with `release/vn.0.x` and checkout a new branch called `rc0/vn.0.m` where `m` is +1 the latest release number. This branch will be used in a PR into `release/vn.0.m` and eventually merged back to `release/vn.0.x`. When making a major release, the process should be the same as minor and patch except begin with a name like `release/vn.0.0-rc0` which contains cherry-picked commits from `release-prepare` branch or merged from `release-prepare` branch. |
There was a problem hiding this comment.
checkout a new branch called rc0/vn.0.m
this rc0/vn.0.m cherry picks from main or release-prepare branch ? if yes, please mention this.
There was a problem hiding this comment.
we do not need rc0/vn.0.m because the release/vn.0.m is rc0/vn.0.m , since we do not keep each release a branch.
| ### Branch: `release` | ||
| There are multiple long lived branches with the `release/` prefix. Each release series follows the format `release/vn.0.x`, e.g. `release/v7.0.x`. The branch `release/vn.0.x` should point to the most updated `vn` release, e.g. `release/v5.0.x` should be the same as `release/v5.0.8` if that's the latest `v5.0` release. When starting a new minor or patch release, begin with `release/vn.0.x` and checkout a new branch called `rc0/vn.0.m` where `m` is +1 the latest release number. This branch will be used in a PR into `release/vn.0.m` and eventually merged back to `release/vn.0.x`. When making a major release, the process should be the same as minor and patch except begin with a name like `release/vn.0.0-rc0` which contains cherry-picked commits from `release-prepare` branch or merged from `release-prepare` branch. | ||
|
|
||
| ### Branch: `release-prepare` |
There was a problem hiding this comment.
is this long lived branch ? do we delete it after the release line finished ? like delete theta-prepare after v7 finishes, and make a new Rho-prepare ?
There was a problem hiding this comment.
it may be useful so as to maintain minor versions prep branch, what do you think?
There was a problem hiding this comment.
it may be useful so as to maintain minor versions prep branch, what do you think?
yeah, we do that as well!
RELEASING.md
Outdated
|
|
||
| ### Major Release | ||
|
|
||
| For a new major release, `m`, after a previous release, `n`, start on `release/vn.0.x` and checkout a new branch called `upgradename-main`(e.g. `theta-main`). This will be the `release-prepare` branch referenced above going forward until the network upgrades with the new Major Release. This branch should act like `main` in that it is the target for new PRs that come in with code meant for the upcoming release. Some PRs that target the real `main` will be relevant to this `upgradename-main`, and should similarly be cherry picked to this branch. Before beginning the intitial release candidate process, this branch should pass the `dev-testnet` tests. Once passing, checkout a new branch, `release/vm.0.x` off `release/vn.0.x`. From `release/vm.0.x` checkout two branched: `release/vm.0.0-rc0` and `rc0/vm.0.0-rc0`. Rebase `upgradename-main` into `rc0/vm.0.0-rc0`. Now open a PR from `rc0/vm.0.0-rc0` against `release/vn.0.0-rc0`. This PR is important as it's the last time code reviewers can see all changes going into the release at once. Last minute changes can go directly into `rc0/vm.0.0-rc0` as well as updaing the CHANGELOG.md. Once the PR has been merged, the `rc0/vm.0.0-rc` branch can be deleted. The `release/vm.0.0-rc0` can be tagged and the release can be published as a pre-release. |
There was a problem hiding this comment.
"From release/vm.0.x checkout two branched: release/vm.0.0-rc0 and rc0/vm.0.0-rc0."
rc0/vm.0.0-rc0 should be checkout out from release/vm.0.0-rc0 , because rc0/vm.0.0-rc0 is like a temporal buffer place to make commits going to release/vm.0.0-rc0 will be clean. for example, the changelog of the release date will be changed at rc0/vm.0.0-rc0 branch before merging to release/vm.0.0-rc0 .
There was a problem hiding this comment.
"Rebase upgradename-main into rc0/vm.0.0-rc0. Now open a PR from rc0/vm.0.0-rc0 against release/vn.0.0-rc0. "
just merge or cherry pick from upgradename-main to rc0/vm.0.0-rc0 is enough ?
rc0/vm.0.0-rc0 contains:
- commits from `upgradename-main
- some updates of changelog.
RELEASING.md
Outdated
|
|
||
| This `release/vm.0.0-rc0` will be used on the public testnet before the upgrade takes place. If there are no issues, it can be re-tagged and re-released as `release/vm.0.0` and used in the final upgrade. Should changes be needed follow the Minor & Patch Release process iterating on the final `rcn` number. | ||
|
|
||
| After a successful release, ensure `release/vm.0.0` is merged back into `release/vm.0.x` and that is merged back into `upgradename-main`. |
There was a problem hiding this comment.
and release/vm.0.0 will be merged to main after the hub start to use vm relaese.
Co-authored-by: Milan Mulji <98309852+mmulji-ic@users.noreply.github.com>
Co-authored-by: Milan Mulji <98309852+mmulji-ic@users.noreply.github.com>
Co-authored-by: Milan Mulji <98309852+mmulji-ic@users.noreply.github.com>
|
Summary of V7 release:
There is one step that after release, we will merge |
|
|
||
| ### Major Release | ||
|
|
||
| For a new major release, `m`, after a previous release, `n`, start on `release/vn.0.x` and checkout a new branch called `upgradename-main`(e.g. `Theta-main`). This will be the `release-prepare` branch referenced above going forward until the network upgrades with the new Major Release. This branch should act like `main` in that it is the target for new PRs that come in with code meant for the upcoming release. Some PRs that target the real `main` will be relevant to this `upgradename-main`, and should similarly be cherry picked to this branch. Before beginning the initial release candidate process, this branch should pass the `dev-testnet` tests. Once passing, checkout a new branch, `release/vm.0.x` off `release/vn.0.x`. From `release/vm.0.x` checkout two branched: `release/vm.0.0-rc0` and `rc0/vm.0.0-rc0`. Merge `upgradename-main` into `rc0/vm.0.0-rc0`.(not directly merge `upgradename-main` into `release/vm.0.0-rc0` is to protect `upgradename-main` from being deleted, any branch merged to `release/` branch will be deleted after merge). Now open a PR from `rc0/vm.0.0-rc0` against `release/vn.0.0-rc0`. This PR is important as it's the last time code reviewers can see all changes going into the release at once. Last minute changes can go directly into `rc0/vm.0.0-rc0` as well as updating the CHANGELOG.md. Once the PR has been merged, the `rc0/vm.0.0-rc` branch will be automatically deleted. The `release/vm.0.0-rc0` is merged again into the `release/vm.0.x` branch, and tagged, then the release can be published as a pre-release. `release/vm.0.x` will also be automatically deleted. |
There was a problem hiding this comment.
I updated this paragraph, due to 1. no more each release is a branch, 2. avoid Theta-main being deleted.
issue is as mentioned here
#1327 (comment)
to avoid automatically delete theta-main,
we can either do the above mentioned method, make a temporal branch rc0/v7.0.0-rc0 off release/v7.0.0-rc0
or we can checkout a new branch off Theta-main, and merge this new branch to release/v7.0.0-rc0 branch. and merge release/v7.0.0-rc0 to release/v7.0.x
please let me know which one makes more sense.
@okwme please check here for the specific steps presently for v7.0.0-rc0. https://hackmd.io/MEpvsls9T1aanPJWXer6Ig #Release Process.
|
attention: Theta-main should checkout from v7.0.x , not v6.0.x, though v7.0.x and v6.0.x are at the same commit. because checking Theta-main off v6.0.x , might mess up the git diff when merging Theta-main to a branch checked out from v7.0.x |
|
The following steps should also be mentioned in this doc:
|
|
@mmulji-ic , should this be closed in favor of the updated process that @yaruwangway was compiling based on @alexanderbez 's input? |
|
closing in favor of #1411 |
closing #1271 that targets #583 in favor of this PR.