DeveloperGuide

This Guide is intended for OpenMalaria Developers (original by @tph-thuering) It contains notes regarding Continuous Integration with github

Versioning

Use semantic versioning as follows:

"schema-MAJOR.MINOR.PATCH" for example: schema-33.0.1

• Increase MAJOR number when the XML is changed or there are bigger changes to OpenMalaria
• Increase MINOR number when a small feature is added without changes to the XML
• Increase PATCH number for bugfixes

The file version.txt should reflect the version. Use "schema-MAJOR-dev" when working on a major feature, while MAJOR is the next version. Or use "schema-MAJOR.MINOR-dev" when working on a minor feature. Bugfixes can still use "schema-MAJOR.MINOR" while working in a separate branch, but must be updated to "schema-MAJOR.MINOR.PATCH" once this branch gets merged to develop or a schema-branch.

Tags and branches

Development usually happens in feature-branches. This means: A developer who wants to work on a new feature creates a branch with a specific name based on master or develop.

A feature-branch name should be speaking. For example: vivax-bloodstage-update

OpenMalaria has multiple different versions in development but only 2 types of builds will be published:

• release (new version with either no change to the XML or a new MAJOR version which changes XML)
• pre-release (new MAJOR version which is being worked on, but not all features are ready for release)

A release or pre-release only happens when people want to use the new version and don't want or are not able to compile it themselves and need an executable of openMalaria to run on their computer or cluster.

Releases are partially automated. If you want to release a new version you can tag a specific commit with the version-name and our continuous integration service will build binaries and upload them to Github Releases

Integrating new features

If you want to work on a new feature, please create a new feature-branch from master or develop depending on urgency and other features.

git checkout master
git checkout -b "YOUR_FEATURE_BRANCH_NAME"
 "Do work here"
git commit
git push "YOUR_FEATURE_BRANCH_NAME"

Once you have a new feature ready you can merge it to a MAJOR branch (named "schema-NUMBER").

How to update to a new version

If you have implemented a new feature or a bugfix, update the version like this:

echo "schema-33.1" > version.txt 
git add version.txt 
git commit -m "Bump version to schema-33.1"
git tag schema-33.1
git push --tags

This will create an openMalaria-binary for download. (This means you don't have to build manually anymore).

If a tag is pushed to our github repository, the following happens:

(ci = Continuous Integration Service, travis-ci for Linux and OS X, appveyor for Windows)

• ci checks out our repository and tries to build it
• ci runs unittests and scenario tests and gives feedback
• ci will upload the build (if successful) to github releases if a tagged commit is successful.

For example see this build for a bugfix (schema-33.0.1): https://travis-ci.org/SwissTPH/openmalaria/builds/71915483#L528

Currently (2015-07-20) builds are Linux-only.

We are working on integration of OS X builds and Windows as well. For more information see: Build infrastructure Milestone