|
| 1 | +# Contributing to PHPUnit Global State |
| 2 | + |
| 3 | +Thank you for your interest in contributing to [the assertwell/phpunit-global-state](https://github.com/assertwell/phpunit-global-state) library. |
| 4 | + |
| 5 | + |
| 6 | +## Code of Conduct |
| 7 | + |
| 8 | +Please note that this project is released with [a Contributor Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms. |
| 9 | + |
| 10 | + |
| 11 | +## Installing a development version |
| 12 | + |
| 13 | +This project uses [Composer](https://getcomposer.org) to manage dependencies. You may install everything you need to get started by cloning the repository and running: |
| 14 | + |
| 15 | +```sh |
| 16 | +$ composer install |
| 17 | +``` |
| 18 | + |
| 19 | +If you plan to work with any of the Runkit-based traits, you'll also need to ensure that Runkit7 is installed in your environment. This can be accomplished easily via [the stevegrunwell/runkit7-installer package](https://github.com/stevegrunwell/runkit7-installer), which is provided as a development dependency to this project: |
| 20 | + |
| 21 | +```sh |
| 22 | +$ sudo vendor/bin/install-runkit.sh |
| 23 | +``` |
| 24 | + |
| 25 | + |
| 26 | +### Running tests |
| 27 | + |
| 28 | +Once the project's dependencies have been installed, you may execute the library's test suites by running any of the following: |
| 29 | + |
| 30 | +```sh |
| 31 | +# Run all unit tests and check coding standards |
| 32 | +$ composer test |
| 33 | + |
| 34 | +# Run only the PHPUnit test suite(s) |
| 35 | +$ composer test:unit |
| 36 | + |
| 37 | +# Check coding standards |
| 38 | +$ composer test:standards |
| 39 | +``` |
| 40 | + |
| 41 | +It is expected that every pull request will include relevant unit tests. |
| 42 | + |
| 43 | + |
| 44 | +### Generating code coverage |
| 45 | + |
| 46 | +Code coverage may be generated for the project by running the following: |
| 47 | + |
| 48 | +```sh |
| 49 | +$ composer test:coverage |
| 50 | +``` |
| 51 | + |
| 52 | +This will generate HTML code coverage reports in the `tests/coverage` directory. |
| 53 | + |
| 54 | + |
| 55 | +## Coding Standards |
| 56 | + |
| 57 | +The project strives to adhere to [the PSR-12 coding standards](https://www.php-fig.org/psr/psr-12/), and includes an `.editorconfig` file to help with enforcement. |
| 58 | + |
| 59 | +It's recommended that you [install an EditorConfig plugin for your editor of choice](https://editorconfig.org/) if you plan to contribute code. |
| 60 | + |
| 61 | + |
| 62 | +### PHP Compatibility |
| 63 | + |
| 64 | +Given that WordPress is one of the main reasons for creating this library, PHP compatibility requirements should match that of the platform (currently PHP 5.6 or newer). |
| 65 | + |
| 66 | +Once PHP 5.6 is dropped as a requirement for WordPress, [this library will aim to quickly add typehints supported in PHP 7.x](https://github.com/assertwell/phpunit-global-state/issues/8) and other PHP 7-specific niceties. |
| 67 | + |
| 68 | + |
| 69 | +## Branching Model |
| 70 | + |
| 71 | +This project uses [the "GitFlow" branching strategy](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow): |
| 72 | + |
| 73 | +* `develop` represents the latest development code, and serves as the basis for all branches. |
| 74 | +* `master` represents the latest stable release. |
| 75 | + |
| 76 | + |
| 77 | +### Example |
| 78 | + |
| 79 | +Let's say you want to add a new `StateOfTheWorld` trait to the project. |
| 80 | + |
| 81 | +First, you would create a new branch to house your work, using `develop` as a base: |
| 82 | + |
| 83 | +```sh |
| 84 | +$ git checkout -b feature/state-of-the-world develop |
| 85 | +``` |
| 86 | + |
| 87 | +Then, in your branch, create the trait in `src/StateOfTheWorld.php` and corresponding test class in `tests/StateOfTheWorldTest.php`, using the existing files as templates. |
| 88 | + |
| 89 | +When you're satisfied with the new trait, commit your changes and open a new pull request against the `develop` branch of the upstream repository. |
| 90 | + |
| 91 | +### Tagging releases |
| 92 | + |
| 93 | +When a new release is ready to be tagged, a `release/vX.X.X` branch will be created using `develop` as its base, then the `CHANGELOG.md` file should be updated with all significant changes in the release. |
| 94 | + |
| 95 | +The release branch should then be pushed to GitHub and a pull request opened against the `master` branch for review. |
| 96 | + |
| 97 | +Once merged, a new release should be created based on the `master` branch, using the format of `vX.X.X` (e.g. "v1.2.3") and containing the contents of the changelog for that release. |
| 98 | + |
| 99 | +Finally, the `master` branch should be merged into `develop`, ensuring the code from the release branch is represented there. |
0 commit comments