Date Recur Style Guide

The following outlines style guide and process for code and strings, applicable to new patches.

• Drupal Coding Standards are the ultimate reference for coding standard.
• When uploading a patch, code should be validated against the Drupal coding standard implemented for PHPCS. At worst, after uploading, Drupal.org will report the number of new coding standards failures in test run results.
• Tests must pass before a patch can be considered for review or commit.
• Coding standards issues or patches are not considered. Or may be committed without credit. Coding standards are enforced on feature/bug fix on a best-effort basis.
• Patches may not include irrelevant code or documentation changes.
• Pull request or patches are required. Code dumps/pastes or Gists/etc are not considered.
• Tests must be provided to be considered for review or commit. If fixing a bug, both a passing (fix and test) and failing test (test only) must be provided.
• All submitted code in the queue is subject to GPL 2.0

Patchflow

• A proper patch must be created via patch or Git. See documentation. Patches designed for email, or generated by IDE's (Storm, Eclipse) are typically not valid.
• Subsequent patches must include an interdiff.

Pull request flow

Alternative to patchflow.

1. Fork the repo https://github.com/dpi/date_recur, and update HEAD with whichever changes are on drupal.org.
2. Create a new branch branched of 8.x-2.x with your changes.
3. Link to the branch from your Drupal.org issue.
4. A patch is also required showing tests pass.
5. Subsequent changes must be new commits, not amendments.

Style guide

• There must be no references to 'date_recur' within documentation. Use "Recurring Date" field, etc.
• There must be no references to MySQL, PostgresSQL, SQLite, etc unless it is a workaround or a unique implementation is required.
• "Time zone" are two words. Use "Time zone" in documentation and PHP. "timezone" may be used for config keys, field column, or database columns.
• RRULE, RRULE string, RFC string, must be replaced with "repeat rule" or similar. Unless specifically referring to iCalendar RRULE.
• camelCase must be used everywhere. Except config keys, database columns, field columns, of references to internal PHP functions or Drupal hooks, which may use snake_case.

Implementation notes

• Occurrences table is considered transitory. Rows may be added or removed at will by any system