Skip to content

Latest commit

 

History

History
106 lines (72 loc) · 5.08 KB

CONTRIBUTING.md

File metadata and controls

106 lines (72 loc) · 5.08 KB
Raw

How to contribute

CakePHP loves to welcome your contributions. There are several ways to help out:

  • Create an issue on GitHub, if you have found a bug
  • Write test cases for open bug issues
  • Write patches for open bug/feature issues, preferably with test cases included
  • Contribute to the documentation

There are a few guidelines that we need contributors to follow so that we have a chance of keeping on top of things.

Code of Conduct

Help us keep CakePHP open and inclusive. Please read and follow our Code of Conduct.

Getting Started

  • Make sure you have a GitHub account.
  • Submit an issue, assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • Make sure you fill in the earliest version that you know has the issue.
  • Fork the repository on GitHub.

Making Changes

  • Create a topic branch from where you want to base your work.
    • This is usually the current default branch - 4.x right now.
    • To quickly create a topic branch based on 4.x git branch 4.x/my_contribution 4.x then checkout the new branch with git checkout 4.x/my_contribution. Better avoid working directly on the 4.x branch, to avoid conflicts if you pull in updates from origin.
  • Make commits of logical units.
  • Check for unnecessary whitespace with git diff --check before committing.
  • Use descriptive commit messages and reference the #issue number.
  • Core test cases, static analysis and codesniffer should continue to pass.
  • Your work should apply the CakePHP coding standards.

Which branch to base the work

  • Bugfix branches will be based on the current default branch - 4.x right now.
  • New features that are backwards compatible will be based on the appropriate next branch. For example if you want to contribute to the next 4.x branch, you should base your changes on 4.next.
  • New features or other non backwards compatible changes will go in the next major release branch.

What is "backwards compatible" (BC)

BC breaking code changes mean, that a given PR introduces code changes which can't be performed by everyone without the need to manually adjust code.

Here are some rules which prevent BC breaking code changes:

  • Configuration doesn't need to change
  • Public API doesn't change. For example, any user land code using/overriding public methods shouldn't break.

Also see our current Release Policy

Submitting Changes

  • Push your changes to a topic branch in your fork of the repository.
  • Submit a pull request to the repository in the CakePHP organization, with the correct target branch.

Test cases, codesniffer and static analysis

To run the test cases locally use the following command:

composer test

You can copy file phpunit.xml.dist to phpunit.xml and modify the database driver settings as required to run tests for a particular database.

To run the sniffs for CakePHP coding standards:

composer cs-check

Check the cakephp-codesniffer repository to set up the CakePHP standard. The README contains installation info for the sniff and phpcs.

To run static analysis tools PHPStan and Psalm you first have to install the additional packages via phive.

composer stan-setup

And after that perform the checks via:

composer stan

Note that updating the baselines need to be done with the same PHP version it is run online. That is usually the minimum version. Make sure to "composer install" and set up the stan tools with it and then also execute them.

Reporting a Security Issue

If you've found a security related issue in CakePHP, please don't open an issue in github. Instead, contact us at [email protected]. For more information on how we handle security issues, see the CakePHP Security Issue Process.

Additional Resources