Pull Request Checklist

Please check the items below that has been performed or verified to be not applicable.

Tests

In general, unit and/or integration tests should be created for new features or bug fixes. The main exception to this is when there are existing tests that used to pass but started to fail. In that case, the PR is assumed to address the issue so that the changes makes existing tests pass. You can run tests using:

• a test script in a package.json, including those in the workspace directories
• follow a README for how to run tests
• use testrun.html page to view and run available client-side tests.

Also, documentation, non-code, non-dependency changes may not require tests.

TODO's

Todo comments should be added for

• application enhancements, such as newly coded features, which usually require additional improvements
• temporary or "quick" fix code, which should have comments

Notable Changes

Noteworthy changes are tracked in the change log and release notes to

• help external feature/application testing
• communicate important changes that application embedders and/or users may care about

See the related Automated Release Notes wiki.

These notes can be added

• directly to release.txt and committed
• to an internal tracking document
• as "conventional" keyword patterns in commit messages. Examples:

// one commit
feat: exciting new feature; // must use semicolon for the parser to exclude subsequent lines
- item 1
- item 2

// another commit
fix: something that used to break; another blurb

Only the message after the colon and first semicolon will be included in the release note. The output from the above examples will look like:

Features
- exciting new feature

Fixes
- something that used to break