-
Notifications
You must be signed in to change notification settings - Fork 27
Contributing
If you're interested in contributing to Iridium then there are a few things you should know. This is to keep things in the project structured and relatively stable - since we work on a rapid-release schedule, pushing out new versions as features exit development.
We follow the Semantic Versioning Guidelines as much as possible, which means our releases are marked with a version number consisting of <major>.<minor>.<patch>.
Patch releases are those which fix bugs, tweak supporting code and modify the documentation without having any effect on the public API .
Minor releases are those which add features or expand the public API in a backwards compatible manner - if you're using v2.6.x and choose to update to v2.9.x you shouldn't have to change your code to keep everything working.
Finally, major releases are those which implement breaking changes to the public API, meaning that code which used v1.x could not update to v2.x without changing the way it used Iridium.
When contributing, we suggest you try to keep your contributions in the patch or minor categories as it will allow us to more quickly merge your changes into the master branch and release them for general use. Most of the time, if you're adding functionality, you will be able to either add extra methods to the API or extend the call signatures of existing methods. Either of these approaches are fine, though we try to encourage the later option as it keeps the API simple and easy to document.
We use Travis-CI to run automated tests on all commits that we push. You can activate Travis-CI on your own fork if you wish by going to their website and signing in with your GitHub account. We suggest that you either run tests on Travis or locally using npm test before opening a merge request - as it will save everyone some embarrassment if your request goes through first time round.
When contributing a merge request you will be required to show that your changes/additions pass these tests before we will merge it. We also ask that new features include a set of tests demonstrating how they work, and that they work correctly.
Also take into account possible failure cases which you have coded against so that future modifications to the code don't break your features by accident.