I'd love to get more developers involved in adding new features and ideas, testing, building themes and apps, etc.
There are some ideas about apps and future development on the Future page.
We can also use help with:
The basic naming conventions are outlined on the Code conventions page. The core design principles and architectural overview are here and here:
To hack on Elefant, please create a fork of the repository, create a feature branch, and make your changes there.
If you are working on a feature or bug listed in our Github issues, please add a comment on the issue to let others know you've ""claimed"" it like this:
Working on this in [https://github.com/username/elefant/tree/branchname]
The link should point to the branch in your fork on Github.
Once you have changes to be included in the main repo, create a pull request so we can track and review the changes before committing.
Here's a great tutorial on the GitHub development process.
Elefant's branching scheme works as follows:
master- This is the main development branch that new features are pulled into, but should be relatively stable since new features are implemented in their own branches.
a.b- Each minor release gets a new branch (e.g.,
1.0) so that updates can be made for it as needed.
feature-x- Separate branch for ""feature x"", to be merged into
Releases are tagged on the branch they were made, using the naming convention
Elefant uses three-digit version numbers of the form
a is the major release number,
b is the minor release number, and
c is the bug fix release number.
Odd minor release numbers are considered development releases leading up to the next even number. For example,
1.1.x is a development release leading up to a stable
Releases are also tagged with a status descriptor, which is one of:
alpha- Incomplete or partially finished work.
beta- Working but needs testing.
rc- A release candidate, requesting further testing before calling it stable.
stable- A release that is considered stable and well tested.
Elefant uses PHPUnit for its core tests, and Zombie.js for interface testing.
The database-bound tests use an in-memory SQLite database instead of mock objects.
The MongoModel tests require a locally running MongoDB instance.
To run an individual test, use:
$ cd /path/to/your/site $ phpunit tests/CacheTest.php
To run the full suite of tests, use:
$ cd /path/to/your/site $ phpunit tests