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.
- 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 methods or change their signatures, deprecate them instead
- Default behaviour "SHOULD NOT* be be changed between minor releases, unless absolutely needed. If 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
- All test suites *MUST* be run be run on TeamCity [3] before merge to master..There *MUST* be , there MUST be no new test failures
- Misc
- Code style *MUST* be 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/