Post-Olympia Branch Management

Background

After the imminent relase of the Olympia network, we will be going into a new phase of development. We will be

1. actively making major changes in the runtime to get it ready for the third, runtime audit: see label audit-3.
2. updating other parts of the system, such as query node, CLI, types, etc. to keep in synch with the runtime changes.
3. possibly doing last minute bug fixes and other enhancements to master as required by circumstances in the production environment.
4. launching NFT features, which will require some runtime changes, in the Rhodes release: https://github.com/Joystream/joystream/issues/3296
5. keeping open the option to launch yet another network after Rhodes which includes some subset (so importantly not all) of changes we have done to the runtime, e.g. new cashout logic, creator tokens, runtime parameters, fees or some other unanticipated changes. This release is tentatively called Ephesus.

Proposal

The biggest challenge here will be how to be able to do work as part of the audit, which has internal inter-dependencies, but where we do not know what needs to go into Ephesus, if anything.

Read the proposed post-Olympia branch-management plan and the linked Rhodes issue (3296), then review the audit-3 work referenced in the issue. Use the branch diagram and release goals to understand the intended separation of runtime changes. Done means the team has an agreed strategy for managing master, audit work, Rhodes, and a possible Ephesus release.