You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overview

TBD

Definitions

TBD

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"
    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"
    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"
  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 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


  • No labels

Apache Ignite