Contributions are welcome and will be fully credited.
We accept contributions via Pull Requests on Github.
- **PSR-2 Coding Standard
** - Check the code style with
$ composer check-styleand fix it with$ composer fix-style. - Document any change in behavior - Make sure the
README.mdand any other relevant documentation are kept up-to-date. - Consider our release cycle - We try to follow SemVer v2.0.0. Randomly breaking public APIs is not an option.
- Create feature branches - Don't ask us to pull from your master branch.
- One pull request per feature - If you want to do more than one thing, send multiple pull requests.
- Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.
If you have access to create releases, please note the following:
- Releases are created automatically when you create a semantically versioned
tag(not a release using the GitHub web interface—must be prefixed withv, i.e.v3.1.2) - Before creating a
tagplease ensure the following:CHANGELOG.mdhas been updated appropriatelyRELEASE.mdhas been updated appropriately—the text of this file will be what is added to the release notes created by the.github/workflows/release.ymlaction. Often this will be the section of theCHANGELOG.mdfor this release but may include more information relevant to this releaseREADME.mdhas been updated appropriatelycomposer.lockis correct—the GitHub action will use whatever version of dependencies in the lock fileconfig/module.iniis created updated by the GitHub action using the data inUpdateModuleIni.phpand the name of the tag. You should keep this up to date but, in case you forget, once you create a tag it will update theconfig/module.iniwith the correct version in the zip file in case you forget before pushing the tag.
Happy coding!