# 0.39.0 Release: What Went Wrong The commit `ae4dcbc2a` was tagged as `v0.39.0-rc0`. Testing was performed by a number of application developers. The Stable Release Managers took care of opening up pull requests in client applications repositories and assisted clients in performing 0.38.x -> 0.39.0 migration testing and verifying bugfixes. Then the [PR #6749](https://github.com/cosmos/cosmos-sdk/pull/6749) fixing the bug [#6745](https://github.com/cosmos/cosmos-sdk/issues/6745) was opened against the release branch. The following `git log --online`'s output shows the branch's commit history: ``` 89ceb62a4 (tag: v0.39.0) Merge pull request #6725 from cosmos/rc0/v0.39.0 4bae3e820 [ci] fix linter (#6795) e42c50c12 x/staking: add call to iterator Close() method (#6794) 04267dd55 add reference to gaia software upgrade ab3254f92 Update changelog 2f779e10a mv NEWS.md -> RELEASE_NOTES.md c25136154 Mege PR #6749: auth: remove custom JSON marshaling d7df1ef86 Update NEWS.md bb7148308 remove pruning info from changelog 98ff8a3a5 update release notes 3e51ee8ff Update CHANGELOG.md 270045e5a update release notes ae4dcbc2a (tag: v0.39.0-rc0) Merge pull request #6707 from cosmos/launchpad/release/v0.39 ``` The PR #6749 went through review and was approved by multiple SDK developers (including a SRM - another release manager gave a good-to-go in the Discord's #launchpad channel); the PR was merged in afterwards. Such pull request [broke backward compatibility with the 0.38](https://github.com/cosmos/cosmos-sdk/issues/6828#issue-664473181) release series. Note: tests and simulations had never failed. Shortly after that, the release was published. # Resolution The Launchpad Stable Release Managers discussed about the options and decided to fix the regression by removing the custom JSON encoding altogether and introducing a 0.38.5 -> 0.39.1 migration. # Release Process Improvements After tagging `v0.39.0-rc0` two more PRs were merged in. The impact of such changesets was underestimated (patches were small and considered harmless). This was the root cause. We've decided to amend the release process as follows: 1. If PRs are merged in after a Release Candidate tag was created (e.g. `-rc0`), a new release candidate tag will be created and clients will be encouraged/assisted to repeat testing on the latest RC tag. 2. Once a release candidate tag is created, the release candidate is **frozen**, meaning that the only PRs that will be merged in are those that fix bugs and regressions spotted during the testing phase of the previous release candidate. This should help reduce the risk of regressions and improve coordination across the board. 3. Stable Release Managers merge rights should be enforced via branch ACLs. Furthermore, Release Managers shall from now onwards give explicit approval directly and only on Github PRs before letting the proposed PRs in. ---- **The Launchpad Stable Release Managers** *Alessio, Ethan, Cory*