Workflow and release cycle - HeloiseS/hoki GitHub Wiki
The release branch
The release branch is gold and will, from v1.6 onwards, solely contain the released versions of hoki (note that v1.5 is the transition to this new workflow and there will be differences between the pypi release and the release branch).
It is protected and any pull requests made to the release branch must be approved by the Code Owner.
Where is the Master branch?
The hoki team is making a conscious effort to do away with historically problematic terminology 1(https://insights.dice.com/2020/06/16/developers-debate-deleting-master-slave-code-terminology/) so we replaced the "Master branch" terminology with "Release branch".
The dev* branches
The development branches are created from release and centralise the addition or modification of features for future releases.
Multiple dev branches can be created for different releases with naming convention devX.Y where X and Y are integers and X.Y corresponds to the future release version.
Having multiple dev branches allows features to be developed and put together on a single branch at a slower pace without messing up the next release.
You should not be committing code to the dev branches directly. You should create pull requests from feature branches (see below)
dev branches should be created by the Code Owner.
The feature branches
New features or significant code modifications should be done on their own branch. One feature == one branch. (And be careful you are working on the right branch!).
Feature branches should be created from the relevant dev branch and merged back to the same dev branch.
All hoki developers can create a feature branch as necessary and create pull-requests to the dev branch.
Ideally, a feature branch would only be merged once unittests have been created
Hot Fix branches
If a bug is reported from a currently released version of the code and needs urgent fixing, hot fix branches should be created from the release branch.
One bug == one branch
They can then be merged back to the release branch and when all sequential bugs have been addressed, a patch should be released on Pypi and in the Github releases tabs.
All hoki developers can create hot fix branches. Merging hot fixes to release and creating the patch will be done by the Code Owner.
Workflow visual summary
Here is a visual summary of the workflow we aim towards
Release cycle
Major hoki releases are associated with major features that often coincide (but not always) with the publication of a journal article.
Major features are only fully released once documentation and tutorials have been created. They may be functional before then, but should remain on the dev branches.