DOCA Dependency Compatibility Policy

The DOCA Dependency Compatibility Policy ensures flexibility and efficiency during updates, enabling customers to upgrade specific layers of their system without requiring a full stack overhaul.

• Decoupled updates: Supports environments where distinct teams manage separate parts of the software stack (e.g., firmware vs. user-space applications).

• Targeted upgrades: Enables upgrades targeted at specific subsets of devices within a server.

• Reduced maintenance overhead: Minimizes downtime and complexity by limiting updates to necessary components only.

• Operational continuity: Guarantees that customer applications continue to operate successfully after updating to a newer software platform release.

This policy applies to all NVIDIA network device products and their associated software and firmware stacks.

DOCA defines two levels of dependency compatibility: Perpetual compatibility and Limited compatibility.

Level 1: Perpetual Dependency Compatibility

• Type: Perpetual forward and backward binary compatibility (e.g., a newer host component must work with an older firmware component, and vice versa).

• Condition: This is the highest level of support. Either the upper or lower layer may be upgraded independently, and all prior functionality is guaranteed to work seamlessly.

• Application: This policy applies to LTS (Long Term Support) update releases within a three-year support window.

Level 2: Limited Dependency Compatibility

• Type: Limited forward and backward binary compatibility.

• Condition: Breaking changes may be introduced annually, specifically with the October GA release.

• Limitation: Compatibility is guaranteed for all releases within a single annual cycle (October through July).

  Info

  The July release is fully compatible with the preceding April, January, and October releases of the same cycle. However, it may not be compatible with the next October release.

• Application: This policy applies to new GA feature releases.

  Note

  This does not apply to LTS update releases, which always follow Level 1 (Perpetual Dependency Compatibility).

The following table summarizes how the compatibility policies apply to specific layers of the software stack:

Compatibility support is a necessary precondition for supporting various customer update flows. While the exact flows are use-case dependent, this policy enables three primary update methodologies:

• Offline update: The system is taken offline during a maintenance window (usually involving a full system reboot) to apply changes. This is the simplest update method.

• Deferred update: New software is deployed without immediate service interruption. The system runs on the old version until a later system reset (determined by administrators) is performed for the changes to take effect.

• Hitless update: Updates are applied seamlessly without downtime or restart, maintaining continuous service availability. This typically applies to more granular components (e.g., a single service update).

  Note

  Since the updated component must interact successfully with the rest of the system's un-updated components, it is advised to utilize containers to achieve this isolation.