ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Version 1/7 - Next » - Current version
Holger Just, 2011-12-18 07:31 pm

The ChiliProject Repository

The main ChiliProject is hosted on GitHub:

The individual developers' repositories are:

Branch Naming Convention

The ChiliProject repository has 3 main long lived branches; stable, master, and unstable. Additional short-lived branches will be present from time to time.


This branch will only contain released versions and should be safe for use in production


This branch contains the latest stable version plus bugfixes/non-breaking changes that will be included in the next version. It should be pretty stable but not as stable as stable. All development should start from here and release branches should be created from here.


This branch is the integration branch for the next major release, it contains a reasonably recent version of master plus feature branches from the developer repositories. New feature development should be branched off from here or if there is pending work that has not yet been merged to master. The goal of this branch is to merge all feature branches together to prepare the next major release, when the code on this branch is stable enough, it is merged to master just prior to release.

release branches

Short-lived release branches are created off of master prior to release for final tests, documentation, version bumps. Those are named release- followed by the version tag as per SemVerTag, for example release-v1.1.2. If some intermediate versions are needed before fully releasing, for example Release Candidates, those versions should be git tagged accordingly, for example v1.1.2-RC1, no new branch or merging is necessary at that point. When the code is ready to release, the branch is merged into the stable branch, the merge commit tagged accordingly (v1.1.2), after that the branch should also be merged back into master to get last-minute fixes into master, the branch can then be deleted.

Branch stability

stable is more stable than master which is more stable than unstable.

workflow_web.png (27.5 kB) Holger Just, 2011-01-30 06:05 pm

workflow.graffle - OmniGraffle source of the branch model infographic (246.6 kB) Holger Just, 2011-02-03 04:57 pm