Overview

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]:

1. MUST - This word mean that the definition is an absolute requirement of the specification.
2. 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.
3. 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

1. API
   1. API compatibility MUST be maintained between minor releases. Do not remove existing methods or change their signatures, deprecate them instead
   2. Default behaviour SHOULD NOT be changed between minor releases, unless absolutely needed. If change is made, it MUST be described in "Migration Guide" [2]
   3. New operation MUST 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
   4. API parity between Java and .NET platforms SHOULD be maintained when operation makes sense on both platforms. If method cannot be implemented in a platform immediately, new JIRA ticket MUST be created and linked to current ticket
   5. API parity between thin clients (Java, .NET) SHOULD be maintained when operation makes sense on several clients. If method cannot be implemented in a client immediately, new JIRA ticket MUST be created and linked to current ticket
   6. All exceptions thrown to a user SHOULD have explanation how to resolve, workaround or debug an error
2. Compatibility
   
   1. Persistence backward compatibility MUST be maintained between minor releases. It should be possible to start newer version on data files created by the previous version
   2. Thin client forward and backward compatibility SHOULD be maintained between two consecutive minor releases. If compatibility cannot be maintained it MUST be described in "Migration Guide" [2]
   3. JDBC and ODBC forward and backward compatibility SHOULD be maintained between two consecutive minor releases. If compatibility cannot be maintained it MUST be described in "Migration Guide" [2]
3. Tests
   
   1. New functionality MUST be covered with unit tests for both positive and negative use cases
   2. All test suites MUST be run on TeamCity [3] before merge to master, there MUST be no new test failures
4. Misc
   1. Code style MUST be followed as per Ignite's Coding Guidelines

[1] https://www.ietf.org/rfc/rfc2119.txt

[2] Instructions for Migration Guide is yet to be finalized; could be skipped for now

[3] https://ci.ignite.apache.org/