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-style
and fix it with$ composer fix-style
. - Document any change in behavior - Make sure the
README.md
and 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
tag
please ensure the following:CHANGELOG.md
has been updated appropriatelyRELEASE.md
has been updated appropriately—the text of this file will be what is added to the release notes created by the.github/workflows/release.yml
action. Often this will be the section of theCHANGELOG.md
for this release but may include more information relevant to this releaseREADME.md
has been updated appropriatelycomposer.lock
is correct—the GitHub action will use whatever version of dependencies in the lock fileconfig/module.ini
is created updated by the GitHub action using the data inUpdateModuleIni.php
and 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.ini
with the correct version in the zip file in case you forget before pushing the tag.
Happy coding!