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.

ChiliProject Repository

Version 7 (Holger Just, 2011-12-18 07:31 pm)

1 1
h1. The ChiliProject Repository
2 1
3 1
The main ChiliProject is hosted on GitHub: https://github.com/chiliproject/chiliproject
4 1
5 6 Holger Just
Some of the individual developers' repositories are:
6 5 Holger Just
7 5 Holger Just
* Eric Davis: https://github.com/edavis10/chiliproject
8 1
* Felix Schäfer: https://github.com/thegcat/chiliproject
9 6 Holger Just
* Holger Just: https://github.com/meineerde/chiliproject
10 1
{{html_comment(TODO: add the remaining individual repositories)}}
11 4 Holger Just
12 4 Holger Just
!>workflow_web.png!
13 1
14 2 Holger Just
h2. Branch Naming Convention
15 2 Holger Just
16 1
The ChiliProject repository has 3 main long lived branches; @stable@, @master@, and @unstable@. Additional short-lived branches will be present from time to time.
17 1
18 1
h3. @stable@
19 1
20 1
This branch will only contain released versions and should be safe for use in production
21 1
22 1
h3. @master@
23 1
24 2 Holger Just
This branch contains the latest stable version plus bugfixes/non-breaking changes that will be included in the next minor version. It should be pretty stable but not as stable as @stable@. All development should start from here and minor @release@ branches should be created from here.
25 1
26 1
h3. @unstable@
27 1
28 2 Holger Just
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. Branching from this branch should be needed only if you rely on 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 synchronized with the @master@ branch, the next major @release@ branch can then be created from here.
29 1
30 1
h3. @release@ branches
31 1
32 2 Holger Just
Short-lived release branches are created off of @master@ (minor releases) or @unstable@ (major releases) prior to release for final tests, documentation, version bumps. Those are named @release-@ followed by the version tag as per "SemVerTag":http://semver.org/, 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 branching 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.
33 1
34 7 Holger Just
h2. Branch stability
35 1
36 1
*@stable@* is more stable than *@master@* which is more stable than *@unstable@*.