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

Add thoughts on a release process

This commit is contained in:
Ethan Frey 2017-06-22 13:04:47 +02:00
parent c9b02909dc
commit 5d147d1673
2 changed files with 38 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
RELEASE.md Normal file
View File

@ -0,0 +1,33 @@
# Release Process
Basecoin is the heart of most demo apps and the testnets, but the last few releases have been a little chaotic. In order to guarantee a higher, production-quality release in the future, we will work on a release process to check before the push to master. This is a work-in-progress and should be trialed on the 0.6.x patches, and used for the 0.7.0 release.
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
* Clarify scope of release
* Create issues
* Write code
* Update CHANGELOG
* Create PR for release
* Update version
## 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)
* 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.
## Release
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
* Upgrade our public-facing testnets with the latest versions

10
ROADMAP.md
View File

@ -12,7 +12,7 @@ Patch release here involve improving the usability of the cli tools, adding subc
**Breaking changes**
* Renaming likely this release may well lead to a renaming of the repository to emphasize that it is a generalized framework. `basecoin` and `basecli` executables will remain with generally unchanged usage.
* Renaming likely: this release may well lead to a [renaming of the repository](https://github.com/tendermint/basecoin/issues/119) to emphasize that it is a generalized framework. `basecoin` and `basecli` executables will remain with generally unchanged usage.
* This will also provide a tx structure that is very different than the current one, and a non-trivial upgrade of running chains.
The next release cycle involves a big upgrade to the core, especially how one can write modules (aka plugins) as well as configure a basecoin-based executable. The main goal is to leave us with basecoin as a single executable with a similar API, but create a new module/middleware system with a number of standard modules provided (and easy addition of third party modules), so developers can quickly mix-and-match pieces and add custom business logic for there chain.
@ -30,9 +30,9 @@ This will be done in conjunction with some sample apps also building on this fra
## Next steps
The following are three planned steps, the order of which may change. At least one or two of these will most likely occur before any other developments. Clearly, any other feature that
The following are three planned steps, the order of which may change. At least one or two of these will most likely occur before any other developments. Clearly, any other feature that are urgent for cosmos can jump the list in priority, but all these pieces are part of the cosmos roadmap, especially the first two.
### ?? - Local client API for UI
### 0.8.x??? - Local client API for UI
Beyond the CLI, we want to add more interfaces for easily building a UI on top of the basecoin client. One clear example is a local REST API, so you can easily integrate with an electron app, or a chrome app, just as if you wrote a normal Single-Page Application, but connecting to a local proxy to do full crypto-graphic proofs.
@ -40,13 +40,13 @@ Another **possible** development is providing an SDK, which we can compile with
Further, when the planned enhancements to real-time events happen in tendermint core, we should expose that via a simple subscriber/listener model in these local APIs.
### ?? - Proof of Stake and Voting Modules
### 0.9.x??? - Proof of Stake and Voting Modules
We should integrate developments on a [proof-of-stake module](https://github.com/tendermint/basecoin-stake) (currently a work-in-progress) and basic voting modules (currently planned) into properly supported for modules. These would provide the basis for dynamic validator set changes with bondign periods, and the basis for making governance decisions (eg. voting to change the block reward).
At this point we would have to give full support to these plugins, and third-party devs can build on them to add more complex delegation or governance logic.
### ?? - Database enhancements
### 0.10.x??? - Database enhancements
Depending on developments with merkleeyes, we would like to increase the expressiveness of the storage layer while maintaining provability of all queries. We would also add a number of new primatives to the key-value store, to allow some general data-structures.