Giters

Joystream / joystream

Joystream Monorepo

Home Page:http://www.joystream.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Joystream Branching Model and Development workflow

mnaamani opened this issue · comments

commented

Branching model and dev workflow

Main Branches

development branch

  • This is the repository's default branch. It holds the cutting development work.
  • Anyone should be able to build and run a new fully functional joystream network with all
    the correct front-end, cli and server applications to operate such a network.
  • Work on new features is merged here.
  • Because it is the default branch the README should also document how to build and join the active testnet.
  • When we choose to launch a new chain we will typically start from the development branch, unless we are having to relaunch with an older version of the runtime.
  • Some examples of what might go here, updating to latest substrate from upstream, totally new modules, dropping old modules or applications, non-backward compatible changes to runtime.
  • We should strive as much as possible to always merge new features and fixes being done in production from master onto development as frequently as possible. This is the responsibility of the repo maintainers but will more often than not require collaborating with the core developers to fix merge conflicts that will surely arise.

master branch

  • master is the production branch that tracks the latest live production testnet.

  • Releases are tagged on the master branch.

  • From a specific commit/tag on this branch one would build the server and client applications to be able to participate on the network.

  • This means we should ensure the HEAD or tip of the branch is always in sync with the current network.

  • To join the active network one must of course use the network's genesis chainspec file which is usually found in the github releases page at the tagged release when the new chain was launched. We can consider adding the file into the repo itself if it is more convenient.

  • New work that builds on the active network, typically runtime upgrades or hot-fixes for active runtime and applications would branch-off from here.

  • If new work is added on master, it should also be merged or cherry-picked onto the upcoming release branch.

Development flow

Network upgrades

When preparing a new release that will be a network upgrade we will create a new branch named with the "codename" of the release branching off master.

This will be a "long-running" branch where the team will collaborate and target their PRs. When the work is complete and ready to be deployed

Additional work on the branch should be limited to stabilizing the release, patches after doing integrated network testing and testing deployment on staging networks.

Once the release is complete at this point a runtime upgrade proposal can be created using a deterministically built version of the runtime (using our docker scripts) from the tip of this branch. Once the runtime is approved we merge the release branch into master and tag it. We should also merge the release branch into development.

Similarly if the team is working multiple releases in parallel, then work for later releases should be based off the immediately next to release branch.

Application updates and bug fixes

Improvements and bug fixes to the applications for the active network can be merged directly into the master branch, and if necessary and still relevant to development branch as well. This will automatically deploy pioneer to production (and hopefully other applications in the future). Tagging is not required.

New applications and Experimental work

Branch off master if it needs to go into an upcoming release.. or development if it will only be introduced into a new chain.

New Features, Major Updates, Deprecating old features

Work that is not dependent on the current live network features should be merged into development branch

commented

  1. Overall looks good, excited to try this.

  2. The general section seems like it should just be under the development section?

commented 
2. The _general_ section seems like it should just be under the _development_ section?

Yes makes sense. Updated.

commented

We should probably move this into a document in the repo itself and close the issue.

commented

What is the status of this information?