Development Process and Branching Strategy

This is a simple document to explain the development workflow within the Syscoin repository.

For members of the core team who have write access to the GitHub repository working on issues from Asana:

• No one should ever commit directly to the master branch unless it is for something small like a checkpoints update.
• All new feature work should be done in branches- these branches can be scoped to a series of tasks/features being worked on by one or more developers.
• When work in a "feature branch" is complete it should be merged to the devstaging-X.X.X branch which is kept in sync with master until it is time for a release.
• At the time of a release danosphere or coderboo will merge devstaging-X.X.X to master and recreate a new devstaging-X.X.X branch.

For members of the team who are not yet permitted direct write access:

• Fork off of devstaging-X.X.X and complete your work in your own personal fork, and then issue a pull request back to devstaging-X.X.X.
• After enough contributions outside members may be approached to join the core team.

For Official Releases:

• After devstaging-X.X.X is merged to master the branch will be tagged using the github-release vX.X.X process and the next release development cycle will begin.