Overview
TBD
Definitions
Review Checklist defines a set of actions every reviewer must check before approving merge of a certain feature. Please make sure to follow these rules when submitting a patch. Otherwise it is likely to be rejected.
Requirements levels are identical to ones from RFC 2119 [1]:
- MUST - This word mean that the definition is an absolute requirement of the specification.
- MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
- SHOULD - This word mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
- SHOULD NOT - This phrase mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
...
Checklist
- API
- API compatibility *MUST* be be maintained between minor releases. Do not remove existing API interfaces, classes, and methods or change their signatures, deprecate them instead
- Default behaviour "behavior SHOULD NOT* be be changed between minor releases, unless absolutely needed. If a change is made, it *MUST* be be described in "Migration Guide" [2]
- New operation *MUST* be be well-documented in code (javadoc, dotnetdoc): documentation must contain method's purpose, description of parameters and how their values affect the outcome, description of return value and it's default, behavior in negative cases, interaction with other operations and components
- API parity between Java and .NET platforms *SHOULD* be be maintained when operation makes sense on both platforms. If method cannot be implemented in a platform immediately, new JIRA ticket *MUST* be be created and linked to current ticket
- API parity between thin clients (Java, .NET) *SHOULD* be be maintained when operation makes sense on several clients. If method cannot be implemented in a client immediately, new JIRA ticket *MUST* be be created and linked to current ticket
- All exceptions thrown to a user *SHOULD* have have explanation how to resolve, workaround or debug an error
- Compatibility
- Persistence backward compatibility *MUST* be be maintained between minor releases. It should be possible to start newer version on data files created by the previous version
- Thin client forward and backward compatibility *SHOULD* be be maintained between two consecutive minor releases. If compatibility cannot be maintained it *MUST* be be described in "Migration Guide" [2]
- JDBC and ODBC forward and backward compatibility *SHOULD* be be maintained between two consecutive minor releases. If compatibility cannot be maintained it *MUST* be be described in "Migration Guide" [2]
- Tests
- New functionality *MUST* be MUST be covered with unit tests for both positive and negative use cases
- Patch for a bug SHOULD have a test confirming that the bug is fixed
- All test suites *MUST* be run be run on TeamCity [3] before merge to master..There *MUST* be no new test failures, there MUST NOT be any test failures. Not important test failures should be muted and handled according to [4] process.
- Misc
- Code style *MUST* be be followed as per Ignite's Coding Guidelines [5].
- Implementor MUST decide whether
Docs Requiered
flag should be left ON
, reviewer MUST check whether decision was correct or not.
[1] https://www.ietf.org/rfc/rfc2119.txt
[2] https://github.com/apache/ignite/blob/master/MIGRATION_GUIDE.txt
[3] https://ci.ignite.apache.org/
[4] Make Teamcity Green Again
[5] Coding Guidelines