New Contributors are always welcome. See the TechnologyChoices page for the languages (and therefore the skill set) needed.

This repository is public, meaning you can fork it and try things out at your leisure.

Branching Strategy

This project will use git-flow - the tool is suggested, the branching strategy is required. See http://nvie.com/posts/a-successful-git-branching-model/ for the branch strategy and http://yakiloo.com/getting-started-git-flow/ for an intro to using git-flow.

In summary:

• master always has the released code. A commit to master requires bumping the version number.
• develop is the integration / common development branch.
• release/... will be used to publish release candidates
• hotfix/... will branch off master if immediate fixes are needed
• feature/.. is where the work is done - these are ephemeral branches and may last only a few hours or weeks.

The branches master and develop will always be here on the main repository. Other branches may or may not as appropriate.

Coding changes should only be done on feature, hotfix and release branches. The latter two should only have bug fix work, the former is primarily for new features, but may include bug fixes.

feature branches from develop and merges (with -no-ff) into develop when complete and are then deleted. release branches from develop and merges (with -no-ff) into master and develop when complete and are then deleted. hotfix branches from master and merges (with -no-ff) into master and develop when complete and are then deleted.

hotfix branches

These branches should be named descriptively based on the issue, including the issue number.

Feature branches

These branches should be named descriptively about the feature (or issue) this is being worked on.

Test strategy

All new code and code fixes is expected to have automated tests that prove the code. Bug fixes are expected to start with the creation of a test that fails, followed by code changes that make the test pass.

Haskell testing is to be done in hspec, which allows the use of hunit and quickcheck as desired.

JRuby / Java testing is done via rspec.

Integration testing / GUI tests are done via cucumber.

Versioning

LQPL follows the reasonably standard three number versioning system: a.b.c

First number

Currently 0 and will remain that way until we can factor 15 :), at which point we will call it 1.0.0.

Second number

Versions with the same second level number should compile and run code from any version with the same second level number. The number will be incremented whenever the actual language syntax changes or we change code generation or the machine significantly enough that this would no longer apply. An example of an issue that would force a second level bump is #8.

Third number

Changes in the third level number indicate fixes / minor changes only. Thus, we are not limited to bug fixes only. For example, if code generation was improved, but did not require any machine changes or LQPL syntax changes, this would only require bumping the third level number.