Development Guidelines

master and devel branches

• master branch is protected, direct commits are not allowed, only pull requests from the devel branch, should be reviewed before commited, update in master branch triggers an update in model version.
• devel branch is protected, direct commits are not allowed, only pull requests from semantically named development branches (see below) are allowed.

Semantic naming of branches and commits

• Semantic naming of development branches: action/keyword, where keyword is briefly description (no spaces) what type of development is done, while action is one of the following:

action	type of changes
feat	new feature added
fix	fixing of bugs, errors, etc
refactor	code refactoring (changes in scripts that don't change output)
style	style/formatting of files, output, etc.
docs	documentation (e.g. readme, tutorial, etc.)
chore	chores such as upgrade of software

• Example branch name: feat/metIDs or fix/duplicateRxns
• Commit messages are named action-object: brief description, where action is the same as above, object is one of met, rxn, gene or comp if applicable, and brief description is a longer description of what development is done.
• Example commit messages: feat-met: matched metabolite IDs to iKS1317 or fix-rxns: remove wrongly annotated reactions.

File formats

• The devel branch contains the model in XML (SBML L3V1 FBCv2), YML and Cobra TXT format. The XML file is the one that should be used for I/O, the YML and TXT files are only used for tracking changes and should not be used as input for making further changes.
• The master branch furthermore contains the model in RAVEN MAT and XLSX format. These are generated using the newRelease.m script.
• At SysBioChalmers, we do most of our development in RAVEN, and use the newCommit.m script in ComplementaryScripts to prepare files (XML, YML, TXT) before each commit.
• It is also fine to use other software for development, but ideally update all XML, YML and TXT files with each commit. At least, each pull request to devel should contain a 'run' of the newCommit.m script, but this can also be done by one of the reviewers.