certusone
/
cosmos-sdk
mirror of https://github.com/certusone/cosmos-sdk.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update RELEASE from learning from 0.6.0

This commit is contained in:
Ethan Frey 2017-06-23 11:10:32 +02:00
parent e225e9a191
commit d845ae007a
1 changed files with 31 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
RELEASE.md
View File

@ -4,24 +4,44 @@ Basecoin is the heart of most demo apps and the testnets, but the last few relea
This is a rough-guide. Please add comments here, let's try it out for 0.6.1 and see what is annoying and useless, and what is missing and useful.
## Preparation
## Planning
* Clarify scope of release
* Create issues
* Write code
* Update CHANGELOG
* Create PR for release
* Create issues (and invite others to do so)
* Create WIP PR for release as placeholder
* Clarify scope of release in text
* Create labels, eg. (0.6.1 and 0.6.x)
* Tag all issues for this release with 0.6.1
* Other, less urgent enhancements should get the 0.6.x label
## Coding
* Freeze tagging more issues for this release
* Update PR to note this
* If you want an exception, you need a good excuse ;)
* Handle all issues
* Write code
* Update CHANGELOG
* Review and merge
* Update version
* Remove WIP flag on PR
* Organize QA
* Prepare blog post (optional for patch/bugfix releases?)
## QA
Once we have a PR for the release and think it is ready, we should test it out internally:
* Code review (in addition to individual code reviews on the merged issue)
* Code review
* Hopefully dealt with by individual code reviews on the merged issues
* A general run-through is always good to find dead-code, things to cleanup
* Review blog post (and run-through)
* Manual run-through of tutorials (and feedback on bad UX)
* Deployment of a private testnet, multiple users test out manually (feedback on bugs, or annoying UX)
* Test out upgrading existing testnet from last version, document or add tools for easier upgrade.
* If outstanding issues here, fix the issues, and repeat.
* If problems arrise here:
* Create bugfix issues
* Fix them
* Repeat QA
## Release
@ -30,4 +50,7 @@ Once QA passes, we need to orchestrate the release.
* Merge to master
* Set all glide dependencies to proper master versions of repos
* Push code with new version tag
* Link CHANGELOG to the [github release](https://github.com/tendermint/basecoin/releases)
* Package up new version as binaries (and upload to s3)
* Upgrade our public-facing testnets with the latest versions
* Release blog post