- Fork the GibbonEdu/core repository on GitHub and clone a copy on your local machine.
- If you’re running cutting edge code, run the
composer install --no-devcommand to install all required libraries in your vendor folder.
- Write some code and push your changes to your repo using the command line or your favourite Git GUI.
- Create a new pull request and fill in the template provided to tell us about your change.
- Be sure you’re submitting your pull request to the development branch (and not master).
- Submissions should have a changelog entry noting what was added, changed or fixed.
If you’re unsure where to begin with GitHub feel free to reach out on the Support forum or check out these great guides: makeapullrequest.com and opensource.guide
We aim to release a new version every 6 months. Starting with v26, releases are every November and April. There is a string freeze one month before each release, where all interface strings fixed and shared with translators via POEditor.
Each version, stable or development, is denoted with a major semantic version (e.g., v16.0.0). Updates to a stable version are only released in the case of a security concern, and are tagged as a patch version (e.g., v16.0.1).
Gibbon uses a simple branching strategy. The current stable version is released and tagged on the
Master branch. Development branches are setup after each release and increment to the next major version (e.g., v16.0.00 to v17.0.00). The dev branch does not currently track semantic versioning, and a built-in updater handles database changes for cutting edge code.
Gibbon depends on a number of libraries written and managed by other developers, which are stored in the
vendor folder. As of v22.0.00, developers will need to use PHP’s dependency manager, Composer, to install and update libraries in their vendor folder. Stable releases include a full copy of the vendor folder and do not require composer.
Our general philosophy is to make incremental, testable changes to an ongoing development branch. To keep things running smoothly—especially as we refactor the codebase—it helps to keep each new change small and self-contained.
There are a few schools running cutting edge code in production which helps to continuously test new changes before release. With this in mind, we aim to keep the development branch as stable as possible.
Pull Request & Code Review
Each pull request should contain only one new feature or improvement. Ideally, split any larger change sets into multiple PRs if they involve more than a handful of files. Long running branches with breaking changes are unlikely to be merged into the core.
Pull requests can be submitted to the current development branch and not to
Master (which is our stable release). Please take some time to describe your changes, there’s a PR template on GitHub to get you started.
Our CI robots will automatically built & test any pull requests. Our code coverage isn’t extensive yet, so a green checkmark on GitHub isn’t necessarily a green light to merge: there’ll always be a human review too.
Each pull request is reviewed by at least one Gibbon Maintainer. Complex changes may require more than one set of eyes and some hearty discussion. Focus on code readability and bite-size commits and your PRs will be in good shape to merge.