Versions Compared

Old Version 10

changes.mady.by.user Dmitry Pavlov

Saved on

compared with

New Version Current

changes.mady.by.user Yakov Zhdanov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. API
    1. API compatibility MUST be maintained between minor releases. Do not remove existing API interfaces, classes, and methods or change their signatures, deprecate them instead
    2. Default behavior SHOULD NOT be changed between minor releases, unless absolutely needed. If a 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. Patch for a bug SHOULD have a test confirming that the bug is fixed
    3. All test suites MUST be run on TeamCity [3] before merge to master, there MUST NOT be any test failures. Not important test failures should be muted and handled according to [4] process.
  4. Misc
    1. Code style MUST be followed as per Ignite's Coding Guidelines [5].
    2. 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

...