doc: merging, branching, release strategy

[boz]

Design and document a release strategy.

There are two main akash components: the blockchain app (./app, ./x/), and the provider services (./provider). For most intents and purposes the provider services are clients of the blockchain components.

Changes to the blockchain component can come in two flavors:

1. state-breaking changes that require nodes to migrate state offline.
2. updates that don't require require state-breaking changes.

The first will require a governance process, the second likely will as well.

Provider services can be released at will. We may want to introduce #211 to encourage providers to stay up-to-date, tho.

[anilcse]

May be we should include upgrade strategy in the title.

I think we can handle state-breaking upgrades also with upgrade module. that looks handy. Otherwise, export, new genesis looks odd for me. I haven't got a chance to see how the state-breaking upgrade works (no-op upgrade using gov + upgrade module), a best chance to test it on current testnet

[boz]

Thanks @anilCSE . Yeah, we need to pin down what exactly the upgrade procedures are for both cases. It will inform how we handle versions from a version control perspective.

[boz]

Note: we'll be using the mainnet branch for now to track the mainnet version of the app (read: no akash modules).